Daniel Iser

@cristianderiquer – Sorry to hear that, do you mind sharing what translation solution your using? Each does things drastically differently, some work fine out of the box, others require limiting what conditions get used.

Our rules are based on post & tax IDs, but one or 2 of them duplicate posts for separate languages, thus creating different IDs, causing rules to seem to break (though not really).

Unfortunately the problem with that setup is it ignores how WP functions as a whole to some degree by constantly overriding global variables that aren’t meant to be changed, with no real simple way to remap things built in.

But that is less of an issue with our plugin and more of an issue with 2 systems using N<->N mapping based on IDs (we map popups to pages/posts/tax, they map pages to translated pages).

Hopefully this was insightful at minimum.

@stevetoms Sorry to hear you had trouble.

As you mentioned adding any rules to the Targeting section will prevent that.

The most common use case for a long time was users wanting a main nav menu item to open a popup, thus the popups should just work on every page with no config.

We got dozens of tickets a month on that issue til we changed it, then none, now we get 1-2 about popups loading everywhere every few months, even with more users.

Changing it now would simply break 100k’s of sites that have had it working, so that’s not really an option.

Hopefully this is helpful. If so would you kindly consider updating your review.

• This reply was modified 3 years, 1 month ago by Daniel Iser.

@skinner009 – Hmm interesting use case. We have a massive rewrite nearing release as v2 which will add block controls as well as a new restriction editor.

We are revamping some conditions etc, but this sounds like it would require a custom condition I’m not sure would be useful outside your use case.

Just so happens though adding a condition isn’t to terribly difficult if your handy with code.

You simply need a function that returns true/false based on what your needs are. You can then using a filter register a new condition in the boolean editor with your function as the callback

Here is the filter in question, and you can see the basic registration needed for a simple true/false function: https://github.com/code-atlantic/content-control/blob/master/classes/Conditions.php#L425-L451

The new version will be slightly different, but we have tried to make sure old registerd conditions will still function fine, they just might not read properly (sentence structure) in the new editor which aims to read more like a series of sentences.

Hope that helps.

@freesong – Ill add to the previous response and point out this is a long time, known limitation of the WordPress nav menu editor. What your actually asking for is a single plugin to replace the entire editor, without breaking any other plugin or theme that has also attempted to customize it in various ways.

Ultimately even if we did build it, this plugin isn’t the right home for that type of functionality.

@mrl4n Appreciate the kind words even if it wasn’t your favorite.

That said we are looking to revamp the entire plugin this year and I’d love to hear your feedback on what others did better, or what we’re missing that could be added.

Is it a specific feature or integration that was lacking?

Though I am working through these, I want to point out that WP core does not even support 8.2. With no plugins installed a clean install throws errors on nearly every admin page due to the updater.

In fact I can’t even install Popup Maker the normal way, it throws errors due to updater class notices that header has already been sent.

Post editor has notices hidden by the block editor. So if your just testing early cool, definitely appreciate the heads up, otherwise I don’t really think you should honestly be running it on a production site at this time with any load of plugins, but thats just my 2 cents

• This reply was modified 3 years, 3 months ago by Daniel Iser.

@cristimacovei21 – First, sorry to hear you had issues.

Losing data sucks, but to be fair there have been no changes in the past year that change or muck with data at all. In fact likely 2 years since that occurred. This would be further evidenced in that there were no mass reports from other users with similar issues, meaning it likely did not come from our plugin’s code (or lack of testing).

Second not sure what you mean by promotional popups, the only popup auto generated by our plugin is set to be disabled by default and meant as example for new users, not promotion.

That said if you had something reset post_meta data or delete it for those popups, it would cause settings loss, and could have even caused a disabled popup to become enabled, but we have no functionality that could cause that fortunately, so hopefully a one time glitch, but it would be a safe assumption the original cause still exists even if our code is gone.

Take care.