Mixed feelings

@harman79 – Sorry to hear that you had such trouble. I am curious if you opened a ticket with our support team via our website or email?

That said a couple of counter points for your reference:

1. By default when you save a popup we prebundle and save all the needed CSS & JS for our enetire plugin (no matter how many extension) into a single CSS & JS file via /wp-content/uploads/pum/ folder. This is the most optimized way to do it, no overhead on every request, only download them once for all pages.
2. Our plugin makes only 2 queries on the front end of any site, one for all popups (posts) and another for their meta. This is done through WP_Query and completely cacheable as to not have any queries on any pages.
3. Our popup html is light weight, you can add 1000 empty popups to a page with less than 50ms of extra delay.
4. Our popups are loaded in the footer of your site by default on any page they are targeted to. If you don’t add any targeting rules, that means they are on every page of your site. But since the #1 usage of our plugin is adding popups to menu items that is ideal default setup for most.

   If you have a lot of popups and they all have heavy media (images,iframes), and you didn’t add targeting rules to limit them to only the pages you need them on, then it could of course slow down your site as all that media is loading hidden in the footer of your site on all pages.

   You can also load some of it on demand via our Remote Content extension but it doesn’t work for all content types.

5. The popups are loaded in the footer pre-rendered because most people use them for things like form plugins, but unfortunately most form plugins do not support loading their forms on demand, their JS requires it to be on the page initially. This is how you get around that.
6. Disabling our CSS will show whatever is in your popups in the footer of your page, as there is no longer any CSS forcing it to be hidden by default. So that is to be expected when you consider #1, #5 above
7. And lastly when migrating to a new server, unless you also migrated the /wp-content/uploads/pum/ along with your wp_options table you would need to edit a popup and hit save to regenerate those css/js files. Otherwise you might end up with broken popups as you found. This is not database stuff breaking, but rather just no CSS/JS files to load.

   By default most all of the relevant data we rely on is in wp_posts, wp_postmeta & wp_options. The only data outside of that is the subscribers table which most sites don’t even use. So those tables + the /pum/ folder in uploads is all it should take.

   Now if you migrated in a non-linear fashion, say exporting popups and themes to xml, then importing them your asking for trouble. They are linked by post ID. That is to say all popups store the ID # of the popup theme they use. If the theme Ids change (which they do on import like that), then it won’t be linked, requireing updates to all popups.

   Further that with if your targeting rules use Post Selected or similar, and all you post ID’s changed, well those are now out of whack to.

   But given a straight sql migration of copying tables, that won’t be an issue.

Hopefully you will reconsider your rating based on the facts. These are common setup issues that our support team deals with regularly, that in some cases we even have documented and guides to get around. But in general our plugin has almost no impact on the front end of your site.

Take care, and I wish you best of luck with future projects (hopefully without the headaches).

• This reply was modified 3 years, 11 months ago by Daniel Iser. Reason: Added notes on migrating vs export/import

Daniel,

thanks for the time you took to reply.

I read through all your replies. I am not sure that I agree to all of it. I mean, the options were there, but they did not really work in practice. Your caching function did not integrate well with other popular caching or optimisation plugins (e.g. wp fastest cache or asset clean up or wp optimise). I got all sorts of funny behaviour, always related to your plugin. I understand that you dont have to be compatible with other 3rd party plugins, but then again this is the essence of wordpress; being compatible.

Upon migration, I also lost some of the data of the popup maker posts, so I am not sure I agree with your point about being purely js/css. I had to remake some of the posts (or maybe all of them, I dont remember).

Your plugin cannot be as lightweight as you claim it to be. All other elements, plugins, data being the same in my website, my mobile page ranking was at around 35-45 with popup maker and 50-60 without popup maker, its functionality being replaced by std tooltips. I know, a tooltip is not exactly the same but in my case it worked just as good.

Anyway, I am not the type of guy that wants to cause trouble and it seems that you value your effort and rigthly so. So, I will leave this review here for a few more days in order for you to see my answer and maybe have a look at these points and then I will delete it.

Thanks

@harman79 Appreciate you taking time to come back.

I read through all your replies. I am not sure that I agree to all of it. I mean, the options were there, but they did not really work in practice. Your caching function did not integrate well with other popular caching or optimisation plugins (e.g. wp fastest cache or asset clean up or wp optimise). I got all sorts of funny behaviour, always related to your plugin. I understand that you dont have to be compatible with other 3rd party plugins, but then again this is the essence of wordpress; being compatible.

Sorry you had issues with those plugins but in all honesty that could be any number of things unrelated to our plugin, for example over aggressive choices in optimization settings which can break any plugin.

That said our optin usage tracking shows that roughly 6.5% of our users are using WP Fastest Cache, so I can’t imagine a widespread issue exists there and hasn’t been reported.

Further we have worked with authors of plugins like WP Rocket, AutoOptimize and W3 Total Cache to ensure our assets are done in a way that should be compatible. This should mean they would be compatible with other caching systems as well ultimately.

But in general out of the box, normal WP setup, default optimization settings, it shouldn’t have any issues. Its literally one JS & one CSS file. The JS file requires jQuery & jQuery UI loaded before it, those are the only requirements, but that is not something out of the normal for WP JS assets, most require jQuery.

Upon migration, I also lost some of the data of the popup maker posts, so I am not sure I agree with your point about being purely js/css. I had to remake some of the posts (or maybe all of them, I dont remember).

If you lost posts from wp_posts table, then I’m not sure how that falls on us. That would be a bad migration in general, not a bad plugin. Our data is stored exactly like posts & pages, no differences at all. We use all built in WP functions to access and write that data, just like WP core does for posts & pages. Hard to see where we could go wrong in that process.

I’ve migrated dozens of sites with popups, again if its a straight cloning of tables there would never be an issue of lost data. So maybe it wasn’t a straight clone?

Your plugin cannot be as lightweight as you claim it to be. All other elements, plugins, data being the same in my website, my mobile page ranking was at around 35-45 with popup maker and 50-60 without popup maker, its functionality being replaced by std tooltips. I know, a tooltip is not exactly the same but in my case it worked just as good.

Gonna ask for some clarification here, are you using a page speed measuring tool to get this data, and do you have an auto open popup on the page that its testing? If so your getting misled.

1. All page speed tools nowadays test in ways that allow them to properly measure PWA’s, or progressive web apps like Facebook, where initially a blank page loads and then the sidebar and feeds load separately. Because of this they continue listening for ~30 seconds after the last recorded request made by the browser. IE last file loaded or ajax request completed.

2. An auto open popup with a delay less than 30 seconds would cause an analytics event to be fired to your server, and possibly images that might be lazy loaded inside its content to be loaded.

So if your using a pagespeed tool and have a popup opening on the page, the scanner will actually give you incorrect results, but that isn’t just with our plugin. But consider this:

1. Our plugin doesn’t even initialize the time delay countdown until the browser has already finished loading the page (document.ready). So if this is what is being detected, its absolutely misleading as the page was 100% usable by the user and finished loading before it even started.

2. If you had social sharing buttons or other social widgets or forms inserted from sites like jotform etc, then the scanner would also pick up the late loading of those things as well, again misleading as most won’t even start to load until the page actually finished already.

These methods are perfect for measuring PWA’s as you can see, but not so accurate for regular sites.

Beyond asking for clarification there, I wonder if by “your plugin” you are also asserting that all the content you place inside your popups is somehow our responsibility to optimize as well? Again there is no measurable impact from empty divs and 2 small asset files. Since that is all we actually provide from our own code, it would be hard to see how the slowness would come from that.

But if you insert large videos and images, or have hundreds of popups with small images even, and did not properly set targeting rules to limit which pages that content loads on then it of course would have a noticeable impact.

Anyway, I am not the type of guy that wants to cause trouble and it seems that you value your effort and rigthly so. So, I will leave this review here for a few more days in order for you to see my answer and maybe have a look at these points and then I will delete it.

I appreciate that, but I don’t want you to remove it if your you feel strongly about it. I’m just trying to make sure we are both on the same page. Its not that I don’t believe you had issues, its that I have answered 30k tickets for this plugin just myself, wrote most all of the code in question myself, so when someone says something that shouldn’t be possible we need to get to the bottom. In most of these cases though it is either set up wrong, a conflict or misleading test results.

Please consider this, yes I’m impassioned, BUT we also have 600k sites using the plugin over the past 6+ years, with all manor of combinations of themes, plugins, hosting environments etc. I didn’t get there without listening to users, implementing feedback and optimizations, patching bugs, and tracking down edge cases. This is no different. But my experience also has alarms going off that something isn’t quite right here for us to get the full blame.

If there is room to improve it, I’m open and listening for those suggestions here and now. But if you see that the info I’ve outlined above accurately describes your situation, then you may be able to reconsider both your future usage of the plugin, and maybe your review.

If not again I’d love to hear more.

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

Daniel,

tbh I cannot find an option to remove my review so I made it fair by changing my initial rating and title. I mean, OK I knew that my review was too harsh the minute I wrote it and I know I would be pissed off if it was for my business….

Just as a final recap from me. I am pretty sure I tested everything thoroughly and I can reassure that I was not overagressive at my caching and/or optimisation settings. I pretty much tried every possible solution. In the end I just had to exclude your plugin from minification of css/js and combination of js to ensure that my site was not broken, albeit with a cost at performance. Deferring or async of the JS of your plugin also did not work (broke site), even though I did not have any popups coming right off at page load. I just had 7-8 popups, activated upon click for certain classes in the body of the page.

Regarding the migration, I did everything by the book, did it manually (used interconnect/it Search and Replace), tried it a few times. The posts, or at least parts of the posts (e.g. clickable classes for pop-up activation) had to be re-created. BTW I am pretty sure that I had a problem with losing clickable class names from within post options even when I reset the popup counter.

All measurements regarding speed were made using the std google lighthouse page. OK, no surprise that my page loading times were better since by removing your plugin, I shaved all the kbs of your JS, CSS files + some extra kbs from being able to unload a couple more jQuery scripts that your plugin was dependent on (mixitup comes to mind but it could be more than that).

Anyway, thanks for the time you took to reply, big ups for your great effort in writing and maintaining such a popular plugin. I am sure you are good at what you do, I am sure that your plugin works for 98% of the people (according to your ratings) but it just did not work for me.

Cheers,
Harry

• This reply was modified 3 years, 11 months ago by harman79.

@harman79 – Happy to address this as a support ticket just the same. You would be surprised how many people have left 1 star reviews that I have converted to 5 stars simply by trying to get to the root of the actual issue and help work around or through it. Probably close to 100 I bet.

> I am pretty sure I tested everything thoroughly and I can reassure that I was not overagressive at my caching and/or optimisation settings. I pretty much tried every possible solution. In the end I just had to exclude your plugin from minification of css/js and combination of js to ensure that my site was not broken, albeit with a cost at performance. Deferring or async of the JS of your plugin also did not work (broke site), even though I did not have any popups coming right off at page load. I just had 7-8 popups, activated upon click for certain classes in the body of the page.

No doubt, not calling your skills into question, just stating experience from 600k sites & 30k tickets. I will admit bugs are possible on our end, though getting less and less likely in non-new functionalities.

In general though we use ASYNC on our JS as well, but again jQuery is likely the key factor here. If it was asynced and came in after ours, well, that wouldn’t work. #1 issue with min/comb setups is maintaining proper ordering.

This is what we have set up with WP Rocket and it sounds like its exactly what you tried:

So I’m not really clear as to how/why/what was breaking with your experience. Did you by chance check for JS errors during these issues?

> Regarding the migration, I did everything by the book, did it manually (used interconnect/it Search and Replace), tried it a few times. The posts, or at least parts of the posts (e.g. clickable classes for pop-up activation) had to be re-created. BTW I am pretty sure that I had a problem with losing clickable class names from within post options even when I reset the popup counter.

Again sorry to hear that. Not really sure where to go with that though if I’m being honest. Having done a lot of migrations I’m not even sure how data could be corrupted in that process unless its being stripped out by the encode/decode process, but that seems unlikely as it wouldn’t just strip out our classes.

That said I would be interested to know if you have the before/after data sets quickly available. Would be nice to know, did post or popup Ids change? If so that would again break a lot if you used IDs to target or set up triggers.

Happy to inspect a site if you have a test set up somewhere. We do it pretty much every day ??

Oh just realized, we don’t combine JS in our screenshot there, but that is actually recommended practice these days as every page might have different needs, and if they are always combined, every page has a unique JS file, requiring it to redownload every time.

The benefits of concatenation are pretty much dead with the advent of HTTP/2 as well with multiple concurrent file transfers now the norm.