We're excited to announce the release of Advanced Scripts 2.6.0, a feature update focused on making the conditional logic more powerful, the user experience more polished, and overall performance smoother than ever!
New Filters for Your Conditions
We've restructured the existing set of filters and introduced 10 new ones. Which allow you to satisfy more complex use cases without coding or custom expressions.
One of the most exciting additions in version 2.6.0 is the new request filter group, giving you powerful ways to conditionally run scripts based on how users arrive at or interact with your pages.
URL Parameter
Check for the presence (or specific value) of a query string in the URL.
Great for personalization, tracking campaigns, or triggering scripts based on something like action=modal or banner=true.
Form Field
Detect whether a specific field has been submitted via a POST request.
This makes it easy to run scripts after a user submits a contact form, filter form, or any other frontend interaction.
Cookie
Target users based on a specific cookie value. Handy for remembering user preferences, tracking return visits, or working with third-party tools that set browser cookies.
Page URL
Use this filter to match against the full URL of the current page.
Perfect for targeting scripts on specific pages, like your checkout, thank you page, or any custom path, with full support for wildcards.
HTTP Referer
This filter checks the previous page URL that the visitor came from (a.k.a. the HTTP Referer header).
Ideal for detecting incoming traffic from external websites, campaigns, or even internal redirects.
Domain Name
You can now match against the site's current domain, perfect for multisite setups or white-label solutions where behavior should change depending on the domain being accessed.
AJAX Request
This filter lets you check if the current request is for admin-ajax.php or not. It’s perfect for controlling scripts that should only run during AJAX interactions, or for skipping logic that isn’t needed during background requests, improving performance and precision.
Post Type Archive
Previously, we offered a Post Type filter that only worked for single posts, which led to confusion for many users trying to target post type archive pages. This often required a custom expression as a workaround.
As of version 2.6.0, you can now directly select a post type from a dropdown list. Quick, simple, and no code needed.
Post Meta (a.k.a. Custom fields)
The Post Meta filter lets you target specific posts or pages based on the value of a custom field.
This is an effective method for conditionally loading styles or scripts.
For example, by adding an ACF checkbox field on the edit screen to control behavior per page.
User Capabilities
In addition to the existing user role restrictions, you now have the possibility to check if a user can perform specific actions like edit_posts or manage_options.
This will come in handy when you want granular control over who can trigger scripts or see certain content.
More Flexibility for Custom Conditions
Previously, the Expression filter was intended for WordPress conditional functions like is_front_page() or is_home(). To ensure these functions worked correctly, the expression was only evaluated after the wp hook fired. While this approach supported all standard conditional tags, it created limitations for users who needed to access simple values earlier in the page lifecycle, such as global variables or constants.
In version 2.6.0, we’ve improved this by splitting the original filter into two distinct options, giving you more control and clearer behavior:
WP Expression
Use this when you need access to WordPress-specific logic. The expression is evaluated after the wp hook, so all conditional tags and WordPress internals are fully available. Ideal for context-aware checks like detecting archives, front page status, or user status.
PHP Expression
This option is great for lightweight logic that doesn’t rely on WordPress functions. It evaluates immediately, making it perfect for checking global variables, constants, or low-level conditions, without waiting for WordPress to load fully.
With this separation, your logic runs exactly when it should, keeping things efficient, accurate, and easier to debug.
The New Match Operator
The new match operator brings powerful pattern matching features that significantly enhance your conditional logic. It’s designed to help you match values like URLs, parameters, or strings using intuitive wildcard patterns, without messing with complicated regular expressions.
Simplified Patterns
Whether you're targeting specific pages, routes, or variable patterns, this operator provides a flexible and readable way to define your logic.
The patterns are internally translated into full string regular expressions with delimiters like /^ and $/, so they must match the entire string unless you include the appropriate wildcards.
That's why understanding the difference between the supported wildcards is essential.
| Pattern | Meaning |
|---|---|
* | Matches any characters except / |
** | Matches any characters including / (good for nested paths) |
? | Matches exactly one character |
+ | Matches one or more of the preceding token or group |
(foo|bar) | Matches either foo or bar |
Examples
Let's take an example for the Page URL filter: https://example.com/wp-admin/tools.php?page=advanced-scripts&edit=99.
Below are some practical examples to help you understand how the match operator works using minimatch-style patterns.
✅ **tools.php**** matches across slashes and query strings, so tools.php is matched anywhere in the URL.
✅ **page=advanced-scripts**
Matches the exact query key-value pair anywhere in the URL.
✅ **/tools.php?page=advanced-scripts&edit=99
Matches the full path and query string segment. No need for a wildcard at the end.
✅ https://example.com/**
Matches any page on example.com regardless of path or query. No wildcard is needed at the start.
✅ **edit=9?? matches exactly one character, and edit=99 fits (9 then 9).
❌ *tools.php** cannot match slashes, and tools.php is after slashes.
❌ http://example.com/**
Protocol is https, not http, so it doesn’t match.
❌ **tools.php?page=advanced-scripts
This is only a partial match of the query string. Must match exactly unless wildcards are used more broadly.
❌ **edit=?? matches exactly one character after edit= while there are two. You should add an extra ? or + to match the extra characters.
❌ wp-admin/**
Missing the ** at the start, so the pattern doesn’t match the beginning of the URL.
When to Use Match Patterns?
While match patterns are easier to use than regular expressions, they should be used wisely. For example, instead of using a pattern like **page=advanced-scripts** to match a query string, it's better to use the URL Parameter filter, which is specifically designed for that purpose.
Also, if you're simply checking for the presence of a word in a string, consider using the contains operator instead of the more complex match operator. It’s faster, easier to understand, and more suitable for straightforward checks.
Use match patterns only when you truly need wildcard support or need to match specific structural patterns.
Conditions Editor UI/UX Enhancements
We've refined the Conditions Editor to improve clarity and usability, especially when dealing with complex or context-aware filters.
Badges for Filter Context
Some filters depend on specific WordPress hooks to access the right data (like posts, users, or conditional tags). To make this clearer, we've added small hook badges (such as wp, init, etc.) next to each filter label. This helps you understand when your condition will be evaluated, reducing confusion and making debugging easier.
Improved Fields Layout
We’ve also redesigned the layout of condition fields. Instead of aligning the filter and operator fields in a single row, filters are now displayed in a vertical stack. This change provides better spacing and alignment, especially since each filter can have different input types and requirements. It’s a small change, but it makes the editor much more intuitive to use.
Better Performance for Large Sites
This update introduces a much faster and more efficient way to load post options for conditions like Post, Post Parent, and Post Ancestors.
We now use a streamlined approach that significantly reduces memory usage and speeds up performance, especially on sites with thousands of posts.
This improvement is automatic and doesn’t require any setup. Just enjoy a smoother experience right out of the box!
Looking Ahead to Version 3.0
With version 2.6.0, we've made major strides toward a more powerful and intuitive conditions engine. From the expanded filter library and better expression handling to the brand-new match operator and refined UI, this update brings more flexibility and control without sacrificing ease of use.
But this is just the beginning. As we get closer to version 3.0, we're laying the groundwork for even more advanced features, including nested condition groups, reusable condition sets, and a fully revamped logic engine that will make building dynamic behaviors easier than ever.
Thank you for your feedback and support, it’s what drives every release. If you have suggestions or ideas, don’t hesitate to reach out. The best is yet to come.
