WEBHAUS

Ok, I understand that this filter is Rank Math specific and disables that particular functionality (those Action Scheduler warning notices) and that is the easy way out, but I’m talking about PHP warnings which are being generated, if we do not turn it off – and PHP warnings mean that the code has an unexpected scenario which needs to be fixed.

Once again I’m talking about this file:
wp-content/plugins/seo-by-rank-math/vendor/woocommerce/action-scheduler/classes/ActionScheduler_AdminView.php

The problem is that if the variable $num_pastdue_actions is only being set when the initial $check variable returns null, hovewer code in any case continues its execution below this check (on line 161) and on lines 191 and 194 tries to output a variable which is not set, resulting with a PHP warning.

The most simple way how you could avoid this warning, is by adding this small fix to the plugin just before the line 184 (contains comment: #Print notice):

if(!isset($num_pastdue_actions)) {
	$num_pastdue_actions = 0;
}

This will check if the variable is set or not, and will set it to 0, if it is not set. As without this fix the code returns 0 anyway in the notice, so the fix will not change anything except removing those two PHP warnings. I like to keep my error logs clean and I don’t want to disable this functionality.

• This reply was modified 2 years, 2 months ago by WEBHAUS.
• This reply was modified 2 years, 2 months ago by WEBHAUS.

I also do not have woocommerce installed.

Didn’t quite get you. You said – actual post types, but if I create a custom post type it is also a real / actual post type and not a virtual one. Since post type archive pages are essential for wordpress development, I,d recommend you to add this feature also on these. I understand you about date and author archive pages – there is no need to add stats bar to them, but for cpt archive pages it would be great. ??

Hello, sorry for this unclear question, I was bit in a hurry. Currently when using your plugin, the client fills in the details on the checkout page and if he bails from it, without submitting the order, the order (products in cart + client info) goes into the Abandoned Carts section, which is good.

The admin (store manager) then sees these abandoned carts and client information in the “WooCommerce” -> “Abandoned Carts” section as a list. This list is grouped in All / Recoverable / Ghost / Recovered sections and each record has an option “Delete”, but no option to recover the abandoned order (e.g. option to put it straight into the orders list with the status of “Pending payment” or something).

Is it possible (presumably in pro version) to get an option to recover this order, so it goes into “Woocommerce” -> “Orders” section with the pending status? From what I understand, now the only way to recover the order (if client has filled in his details), is from the e-mail which goes to the client.

Thanks,
Edgars

Hello, after updating to the latest version, problem still pops up, but this time only on the line 213. Please update that too.

Thanks

Hello,

Solution works, but it is not wise to change anything under plugin directory which is installed from WordPress repository (next release of the plugin will come and the “solution” for this user is gone, because files will get overwritten).

The problem actually lies in the improper usage of text domains, which are not intended to be used as variables or constants but strings. When a variable or constant is used as a textdomain, many on-site translation tools will fail to recognize it, because they do not parse PHP. Technically ofcourse this method will work, but it is much less friendly, and the only reason developers choose to use it – is to avoid copy-pasting textdomain again and again, and again (which is actually what everyone should do).

For example, file “class-woocommerce-product-attachment-public.php” contains this code on line 668:

esc_html_e( 'Please Login To Download Attachment', $wcpoa_text_domain );

Because of variable $wcpoa_text_domain, it is not recognized in latest WPML release (and most probably Loco Translate does not recognize it too). When we change it to:

esc_html_e( 'Please Login To Download Attachment', 'woocommerce-product-attachment');

Everything works great! Anyway @dots, thank you for your wonderful work on the plugin, I hope that my advice will be useful to you.

For the user I can currently recommend to add a few thousands to the plugin version number so you dont accidently update it, when the new release is out and you get a notification.

Regards,
Edgars from WEBHAUS

Hello,

Just go to the file: /wp-content/plugins/jquery-manager/jquery-manager.php,
and change the non-static method to static on Line 170.

FROM:
public function autoptimize_support( $dontmove_array ) {
TO:
public static function autoptimize_support( $dontmove_array ) {

I don’t see a single reason why this function could not be static, because its only purpose is to pass that path to Autooptimize plugin.

Regards,
Edgars from WEBHAUS

Hello,

First of all – thank you for your wonderful work,

For easier content management, I would recommend to load a separate settings object for each language, if languages are present. This would allow to declare what to do with the cookie consent window in each language, which, from my opinion is the best approach.

Personally I would implement support only for WPML, since it is more popular. So I’d – 1) Detect if WPML is present, 2) Get a list of available languages, 3) Save and load different settings for each language code 4) If wpml is not present, load settings the old way.

OFFTOPIC: Background color for the consent window does not allow rgba or eight character hex codes and therefore it can’t be made semi-transparent. I would advise to change this too.

For now, I will customize your plugin so it fits my needs, but I’d appreaciate much, as many other users of your plugin, if you could find some time and implement these changes.

Thanks,
Regards,
Edgars from WEBHAUS

• This reply was modified 4 years ago by WEBHAUS.
• This reply was modified 4 years ago by WEBHAUS.

Hey Mateusz!

First of all thank you for your wonderful plugin. As a hosting provider myself, usually we don’t deal with this kind of stuff, since the client configures his website himself, including DNS settings and what is being cached and what’s not (except some fancy setups). From the information which you have provided, my first bet would be on CloudFlare – large portion of websites these days use their free plan to improve performance and caching, and Cloudflare is well known for caching and serving the cached stuff from their servers instead of the origin web server. It is also well known for causing problems with many WordPress plugins, and I could even bet that this is probably the case.

To avoid further questions from the users of your plugin, I would advise to be supportive and add some tips or examples (where to look or what could be wrong) in the plugin notice about “Server configuration error”.

Regards,
Edgars Abolins

Hello,

I see you are using PLESK (https://knet-beton.de:8443/) on your server, and WordPress Toolkit’s “Hotlink Protection” default image (wpt-hotlinked-image-stub.png) is present under your public directory (https://knet-beton.de/wpt-hotlinked-image-stub.png). This problem may be related with recent PLESK WordPress toolkit update (v 3.5 on Nov 29).

https://talk.plesk.com/threads/wordpress-toolkit.343831/page-6#post-856684

They added a new feature “Hotlink Protection” under “Check Security” page. Log into your PLESK panel (https://knet-beton.de:8443/), select your domain, and click on “Check Security” page (WordPress Toolkit option). Then click on “Roll Back” button near the “Hotlink Protection”, if it is present. I guess, when you tried to improve security settings for your website, at some point you turned this feature on.

This “Hotlink Protection” doesn’t work properly on some setups (for example: websites with CloudFlare enabled, etc)

Regards,
Edgars

• This reply was modified 5 years, 11 months ago by WEBHAUS.
• This reply was modified 5 years, 11 months ago by WEBHAUS.
• This reply was modified 5 years, 11 months ago by WEBHAUS.

Wow! I’ve never seen that someone would solve bugs this fast for WordPress plugins. Usually it takes weeks for others. Thank you for the hard work you do! ??

Thank you! I will check it out. ?? Have a good one!

From my understanding, a simple change of a function name “__fs” to, for example “_efl_fs” would work. Error message says it all: “PHP has reserved all method names with a double underscore prefix for future use”

Lets hope the author will make this small change soon.

@gbpsports

The way I do these things is:

-) I never use any kind of auto update mechanisms for WordPress related things (as I said previously: It’s a ticking time bomb);
-) Updating WordPress themes and plugins every day surely is an overkill. Updating plugins once a week is enough for me, and for some highly customized websites I’ve even disabled updates at all. (it’s really not a security risk, if you know what you are doing and have proper security measures in place)
-) Usually making a database backup before plugin updates is enough (since you can always revert to older version, if something goes wrong), but for theme – make sure you backup its directory too, before updating it.
-) I try to make these kind of changes in night hours, when there are less people active on websites;

And if we are speaking about critical / highly important websites, then you must always make changes on a working test version (beta version, clone, staging mode, whatever you call it), before actually updating something on the live website. Full backup in this case is a must have, and no auto updates!

I’m using plugin auto update and my post-man plugin was auto updated late night

@gbpsports Despite that I would also like to see a more controlled release mechanism for WordPress plugin and theme related updates (that’s only a wish), I would like to tell you one thing:

Even I don’t have the guts, to enable auto updates on a live website. That is a ticking time bomb and you should NEVER do that, because this isn’t the only case, when a simple WordPress plugin or theme update breaks something. There are a lot of such cases.

PS: Some psychos enable this feature for the whole server, in the same time not realizing what harm it could make, and then one day they wake up, and see that 100+ of their websites are not working. Only imagine how many hours are needed to fix such a mess.

• This reply was modified 6 years, 7 months ago by WEBHAUS.
• This reply was modified 6 years, 7 months ago by WEBHAUS.