MegaZ
Forum Replies Created
-
Come on now guys, fix this damn problem! My site is running 4.1.26 and I am still experiencing the same error:
PHP message: PHP Fatal error: Class ‘WC_Integration’ not found in /wp-content/plugins/woocommerce-shipstation-integration/includes/class-wc-shipstation-integration.php on line 10
You guys need to fix your software because releasing it!
Forum: Plugins
In reply to: [Jetpack - WP Security, Backup, Speed, & Growth] Lazy Images – No JavaScriptOK, after digging through the code it appears that the plugin actually does insert <noscript> data for images, but only within the content of articles! By default, I had lazy load working on the front page of my site and none of the images were showing up there. My solution was to exclude the homepage images from lazy loading, but it would be nice if the plugin had a way of detecting where it is running.
Also, when Javascript is disabled, the initial image takes up enormous space, because it still has its height and weight properties defined. The best way to get around this would be to assign a CSS class that hides that image by default, so that we don’t end up with empty spaces above images.
Hope this can be done sooner than later, or it looks pretty bad for those who disable Javascript.
Dat, I found the issue – it was because I was minifying the related-posts.js file and it was loading on every page, even though the new script was pushing for the minified related-posts.min.js version. This caused the script to run twice and hence show double results. As soon as I removed related-posts.js and replaced it with related-posts.min.js in the minification of W3TC, the issue went away.
Thanks for looking into this!
I disabled event tracking to prevent issues with your plugin, that’s why you don’t see it.
I am using W3TC Minify to minify both js and css files and I have surely cleared the cache. Like I said, the track outbound links option is the issue here – as soon as I turn it on, the debug shows up when I inspect the page with Chrome.
And I an not including any MonsterInsight’s JS files when minifying JS or CSS.
Here it is: Photography Life
I figured out what’s broken. It is the “Track outbound clicks and download links” feature. The moment it is enabled, the debug mode gets turned on. Please fix ASAP, as I am sure many plugin users are utilizing this feature.
Except the new release does nothing to fix the problem. You guys should be testing releases before publishing them. My busy site has been down for half a day because of the issue and after updating to 6.0.13 and clearing all caches, the problem remained.
James, thanks for taking care of this issue so quickly and pushing out the updates.
While the temporary fix of defining not to use sessions works for now, I would encourage you to update the code so that the session_start directive takes place right before you start working with sessions, within the PayPal express code. This way, sessions are never touched in the first place, unless PayPal is used.
Now the current issue with the plugin still remains for those who don’t know about this particular workaround – the default behavior will always kill caching as it stands, which is not good. The default behavior of any plugin should never be to start sessions – please refer to WordPress documentation, which clearly states that WordPress does not use sessions and instead relies on cookies for storing any temporary or session data.
Try this yourself – on any install of PM Pro, try to grab the front page of the WordPress blog using curl. For example: curl -I https://blogname.com. You will see that with your plugin enabled, curl will return a PHPSESSID header, which is the indication of a session start. With such behavior, try to put this website behind a reverse proxy (say Cloudflare) and see that it will not do anything, since the pages will never be cached. Cache will always return “miss” for session-enabled pages.
I suggest we build a better world with not initializing sessions in plugins, unless one is in the process of checking out via a gateway such as PayPal.
Hope it makes sense – I am sure many of your current plugin users would appreciate such a change.
Sincerely,
NasimJason, please take a look at the paid-memberships-pro file – session_start literally initializes with the plugin, at the very beginning. This is very bad practice and coding. If your intent is to only initialize sessions for PayPal express, then you should not start sessions with the plugin.
Because of this, every single person who gets your plugin installed literally kills any kind of caching. When a session is pushed at the start of the front page, no caching engine will ever work – even Cloudflare will have zero efficiency as the frontend proxy.
Please fix the code – you can simply look for session_start throughout your code base and remove it.
Here is how the uncommenting looks like for those who don’t know:
define(“PMPRO_DIR”, dirname(__FILE__));
require_once(PMPRO_DIR . “/includes/localization.php”);
require_once(PMPRO_DIR . “/includes/lib/name-parser.php”);
require_once(PMPRO_DIR . “/includes/functions.php”);
//require_once(PMPRO_DIR . “/includes/updates.php”);
require_once(PMPRO_DIR . “/includes/upgradecheck.php”);Once you do that, PMPRO will work just fine and won’t bog down your server.
Sucks when you have to dig into untested code by developers, but I found the issue.
Edit paid-memberships-pro.php and uncomment the following line:
require_once(PMPRO_DIR . “/includes/updates.php”);Looks like the updates.php script is causing a loop, generating thousands of cron jobs continuously. Really bad code and that’s what has changed from the previous version.
Developers: please make sure to test your stuff on the server before rolling out updates. You could be killing people’s servers like you have done with mine!
Reviewing cron entries right now and there are hundreds of thousands of these. Seriously?!
My site was brought down thanks to this idiotic DB update!
What are the developers thinking about before implementing such idiotic code?
This is really bad – I am uninstalling the plugin until the issue is resolved.
Forum: Plugins
In reply to: [W3 Total Cache] Terrible Technical SupportI must chime in on this issue as well. These crooks took my $99 and never refunded my money back for the crap product that does not work. Tried to reach out 3 times, never got any response back.
This plugin should be removed from the repository for such horrific practices. Looks like I am not alone either!
I have contacted my bank, but it takes a while for them to process such requests, since you have to explain in writing what happened.
EVERYONE, BEWARE AND NEVER BUY ANYTHING FROM W3TC!
Forum: Plugins
In reply to: [WooCommerce] Search function not workingOK, this is really weird. I searched for a client’s name “wright” and it returned every order. Then I put the order # and it found it fine. Then I searched for the email address and it found it. What’s going on?
Sean, thank you for following up. Looks like you have been doing a great job in updating the script. Thank you! I will be testing the plugin in a live environment later this week and let you know if anything comes up ??