mirror of
https://github.com/simstudioai/sim.git
synced 2026-09-24 15:45:35 +08:00
Waleed
a08da86dff
* feat(wordpress): add category/tag CRUD tools, fix delete-status and dead-field bugs
- Add wordpress_{get,update,delete}_category and _tag tools for full taxonomy parity
- Fix `deleted: data.deleted || true` always evaluating true across all 6 delete tools (posts/pages/media/comments/categories/tags)
- Remove dead `force` param from delete_media (endpoint always force-deletes; param had zero effect)
- Remove unwired `hideEmpty` block input
- Normalize search_content perPage/page visibility to user-or-llm for consistency
* fix(wordpress): use ?? instead of || for zero-valued numeric fields in delete_category/tag
count and parent can legitimately be 0 (empty term, top-level category); || was
dropping those values, same antipattern already fixed for `deleted` in this PR.
Flagged independently by Greptile and Cursor Bugbot.
* fix(wordpress): use ?? for zero-valued numeric fields across all delete tools
Same || antipattern already fixed for category/tag delete tools was still
present in delete_post/page/comment/media for id, author, featured_media,
menu_order, parent, post — all legitimately 0 in common cases (no featured
image, top-level page/comment). Found by a final independent validation pass.
* fix(wordpress): don't drop categoryParent=0 (root-level category) in block param mapping
Truthy check on params.categoryParent treated a resolved numeric 0 (root-level,
no parent) as unset. Flagged by Cursor Bugbot on create_category/update_category.
* fix(wordpress): don't clear category/tag description on update when field left blank
description used !== undefined (numeric-field convention) instead of a truthy
check (string-field convention used everywhere else in this codebase, e.g.
update_post/update_page excerpt), so an untouched empty description field
silently wiped existing text on every update. Flagged by Cursor Bugbot.
* fix(wordpress): fix search type/subtype mislabeling, complete I/O exposure gaps
- search_content.ts: type param was mislabeled with subtype's vocabulary
(post/page/attachment); real WP type enum is post/term/post-format. Rewired
the block's Content Type dropdown to map to subtype (which is what
post/page/attachment actually filter), not type.
- Widened subBlock conditions so params already read by tools.config.params
are actually reachable in the UI: commentPostId for list_comments,
categories/tags for list_posts, parent for list_pages.
- Added missing subBlocks for tool params with no UI path: comment
parent/authorName/authorEmail/authorUrl (create_comment), media description
(upload_media), author filter (list_posts).
- Extended the ?? / !== undefined fix (already applied to categoryParent) to
the same class of param across the block: featuredMedia, page parent,
menuOrder, and the new commentParent/listAuthor mappings.
- Fixed featuredMedia/parent truthy-check inconsistency in create_post,
update_post, create_page, update_page, create_category, create_comment
body builders to match the !== undefined convention used elsewhere.
Found by an independent final validation pass across 3 parallel agents.
* fix(wordpress): keep searchType subBlock id to preserve saved-workflow compat
The type/subtype fix should only change which API param the field feeds
(subtype, not type) — renaming the subBlock id to searchSubtype broke
already-saved workflows with a search content-type filter set, since the
block would stop reading the old searchType key. Reverted the id rename,
kept the underlying subtype mapping fix. Flagged by Cursor Bugbot.
* fix(wordpress): remove invalid Attachment search subtype, fix listAuthor input type
- Search Content's "Content Type" dropdown offered Attachment, which maps to
subtype=attachment. WP core's WP_REST_Post_Search_Handler explicitly
excludes attachment from valid subtypes (media isn't searchable via
/search) — selecting it guaranteed a 400 rest_invalid_param. Removed the
option; only Post/Page (the only valid subtypes) remain.
- listAuthor was declared type: 'string' in the inputs catalog despite being
Number()-coerced before use, inconsistent with every other ID-like field
(postId, pageId, categoryId, commentParent, etc. are all 'number').
Found by an independent final pre-merge validation pass, requested before
merge to be certain of full API alignment.