Webcasata Content Filter

1.4.0

• Added a per-filter “Card Button Label” field under Display Options: give each filter’s card
  button its own text (e.g. “Read more about doctor” for a Doctors filter, “Visit Hospital” for a
  Hospitals filter) instead of the fixed “Read More”. Leave it blank to keep the default text.

1.3.0

• WooCommerce compatibility: filtering the “Product” post type now shows each product’s price and
  the correct Add to Cart button (simple, variable, external — WooCommerce decides) on every
  built-in card template, with the same AJAX add-to-cart behavior WooCommerce’s own templates use.
• The “Select post type” step now only lists post types that actually have a public taxonomy to
  build tabs from. Page-builder-internal post types (e.g. Elementor’s “Template” and “Floating
  Element”) no longer clutter the list; any post type with a real taxonomy attached is unaffected.

1.2.0

• Refreshed the whole admin area — filter list, the Add/Edit wizard, and Settings — with a cleaner
  card-based layout, refined spacing/colors, and smooth toggle switches for every on/off option.
• Added per-filter “Card Elements” toggles under Display Options: show or hide the Title, Date,
  Username/Author, Excerpt, and Comment Count independently, for every built-in template. Off by
  default is “show everything,” so existing filters keep looking exactly as they did before
  updating.

1.1.4

• The “Upgrade to Pro” admin banner is now permanently dismissible: clicking its close button
  hides it right away and remembers the dismissal per admin user, so it does not come back on a
  later visit, a different screen, or a new browser session.

1.1.3

• Changed the wbcf_after_save_filter extension hook to pass only the filter ID, not request
  data — consumers now read and sanitize their own specific form field directly from $_POST
  inside their own callback, matching how core’s save_post hook works, rather than receiving
  raw request data as a hook argument.

1.1.2

• Tested up to WordPress 7.1.
• Simplified an internal function name back to the plugin’s standard “wbcf” prefix for consistency
  (was temporarily longer than necessary during an earlier naming fix).
• Documented, in code comments, why template/view files’ local variables aren’t further prefixed:
  they’re always included from within a method’s scope, never loaded standalone.