not working on specified posts or tags

@lorik84 – Popups do not use the typical flow and thus cannot be restricted in typical ways. You can use PHP filters to restrict user roles, or you can look at our Advanced Targeting Conditions. This wasn’t done in an effort to squeeze users, but is simply due to how popups can be mapped to many content types.

If you want to add an issue we could possibly filter if the user has permission to view a post/popup, but currently any published popup can be targeted anywhere based on conditions. Conditions can vary from content to user to browser and can be applied via PHP or JS making it super versatile if you wanted to filter it manually it wouldn’t be too difficult.

As for the first issue you described, sounds like a UX issue we have resolved by completely redesigning the entire UI / UX for conditions in v1.4 which is in public beta. In the current version checking the box for a page/post/taxonomy != adding it to the list of selected posts. You still need to click the Add Selected button just below the checkbox list. You will then see a tag style list of selected pages with x icons to remove them.

Also popups are generally targeted to the content of the page for best result, is your page a one page app that doesn’t have a unique area for members with role x? IE do you not have a dedicated members area of your site with unique pages/urls that you could target specifically? If not, that is understandable and definitely solvable, just a question of how your app is set up.

On the note of targeting posts by tag / category. This is also built into v1.4. If you look at the screenshots here you can see Posts with Tag in the list. It will automatically show options for any public post types and taxonomies as well as various direct integrations we have made for things like WooCommerce conditions.

You hit another issue with the question about popup tags and categories. They are simply for organization, as we have some users who have dozens and even a few with hundreds of popups. That is what it was for. in v1.4 it is made optional. We even include a check during migration to see if they are in use currently, if not it will disable them to clear up UI space.

We are working hard to revamp the entire UI / UX over the next few versions (1.5-1.7). Each will signifigantly replace existing antiquated ui’s and the code that manages them. Our new Triggers, Conditions & Cookie UI/UX are backed by a very stable Fields API. All completely extendable with just a few extra arrays and a register_trigger style function. We want to make it simple to use and just as easy to customize.

Luckily seems we have already solved 100% of the issues you have pointed out in v1.4 so I welcome you to try it out yourself now.

https://wppopupmaker.com/version/1.4.0-beta1

@lorik84 – Not a problem. If you don’t have a ton of popups you may try the migration process. It should migrate existing triggers, conditions etc.

Hope that helps.

@lorik84 – Can you maybe do a quick screncast of the first issue you mentioned. We have had over a dozen testers prior to public release and focused on how the entire flow went from fresh install.

TBH that sounds more like the browser served you cached admin JS for our plugin until you pressed updating doing a POST to the browser forcing it to refresh. Can you add a new popup and see if the experience is the same after fresh clear of browser cache?

PS Not 100% sure exactly what you mean except that when you select Posts With Category, that the next field doesn’t appear. In which case definitely sounds like cache.

OK now onto other questions:

First concerning the auto open settings. They and all of our triggers settings have been moved to the new Add / Remove setup called “Triggers”.

There you can add multiple auto open trigger with different settings, checking different cookies for instance.

If you see a trigger there already then we imported it from the old auto open settings. Click the blue trigger link or the pencil button to edit its settings.

That is a view counter for basic analytics. We will be adding basic conversion tracking in the future as well. It doesn’t track page loads, it tracks actual opens via AJAX pings and should be really accurate ( even cross domain 😉 for future )

For no cookie simply edit your trigger, go to the cookie tab and remove any cookies listed there. Then it will skip checking for them.

This is simply because we disconnected triggers from cookies, so that you can now relate multiple triggers to multiple cookies in an N:N relationship. Now there are truly no limits. This also means you can change a trigger from using one cookie to another and back again for instance in the case of a sale ad during the holidays but back to regular ad for rest of the year.

Hands down the new version is more powerful and feature rich than the old version. We have simply reorganized, no functionality has been removed, only made more flexible, reliable and simpler to maintain and add to. I would not suggest going backward. We are working on a welcome page in v1.4 that will outline the changes as well as some documentation to make the transition and changes easier. Overall we are trying to simplify the user interfaces by condensing them and placing less restriction on things like cookies. They are now 100% under your control in terms of name.