JP3

Thanks for the link.

It appears that I’m asking your plugin to do more than it was designed to do using the default WP Cron system. I’m calling cron jobs every 5 seconds, 10 seconds, and so on to process single API calls and responses for multiple custom queues.

I’m going to try Advanced Cron Manager, and Advanced Cron Scheduler to see which one fits the bill best.

Thank you for pointing me in the right direction! I think for less demanding and less frequent tasks, your plugin would be perfect and I’ll keep it mind for the future.

Spoke too soon. I have a custom cron job that I can’t edit at all. The filter trick isn’t even working anymore.

I was able to delete it, but every attempt to edit it gave me the dreaded “selected cron job does not exist” message, even though it did exist, and was executing properly on-schedule.

Kept playing around with it, and now it seems to be working as expected. Not sure why I had the “does not exist” issues above, but it seems to have resolved itself. Marking as solved for now.

I didn’t understand the google maps connection myself, which is why I posted.

I was going to send you a link, but I recently migrated servers, and on the new server the error still exists, but doesn’t indicate your plugin like it did before.

New server, same “cross-origin” error with google maps, but now it doesn’t specify any file/source as the culprit.

Probably a conflicting plugin, except I don’t have any that interact with google maps in any way (that I’m aware of). I’ve got something funky going on, but it doesn’t seem to be your plugin like previously indicated.

Marked as Solved. This isn’t your problem.

Just downloaded the latest update and can confirm that the original issue with “Appearance -> Customize -> Widgets -> per-widget-area” is resolved.

Marking as resolved!

Just Awesome! Confirms my reasons for using this plugin as a standard go-to for every site I develop ??

Cheers for that code snippet! Total Lifesaver!

Awaiting a fix for the customizer styling soon. No rush. I can work around it for now, but others may want/need it more than me.

Got another strange scenario doing the same thing. Possibly related.

I created a custom post_type that uses the Gute’ editor and Gutentor blocks.

Admin panel displays them proper. Front-end renders them proper.
Standard archive and singles render properly.

Using those same posts from that same post_type in a custom WP_Query loop in the main index.php (or any other template file) looses custom styles, and no assets for Gutentor are loaded. Even with “global loading” enabled. Just like the widget scenario above.

Thanks for the attention on this.

Just found more clarifying info:

I’ve added theme support for
‘widgets’,
‘widgets-block-editor’,
‘core-block-patterns’,
‘wp-block-styles’ and
‘html5’ ( for ‘comment-list’, ‘comment-form’, ‘search-form’, ‘gallery’, ‘caption’, ‘style’, ‘script’ )

1.) In the wp-admin panel, going to Appearance -> Widgets:
Gutentor seems to be applying custom settings just fine, saving them, and displaying on the front-end properly.

2.) In Appearance -> Customize -> Widgets -> per-widget-area:
Gutentor applies saved values from method 1 above, but any changes revert it back to Gutentor defaults, and on save (“Publish”), saves default values over custom ones. Of course then the front-end is rendering default styles.

Until this is worked out, I’m sticking with method 1.

If needed, I can set you up with an account on the dev site for this.

Looked at my code for a few minutes and wasn’t happy with it. Too long. I turned your 1-liner into a 15-liner ??

Here’s a 1-liner instead:
add_filter( 'block_categories'.( ( version_compare( get_bloginfo( 'version' ), '5.8', '>=' ) ) ? '_all' : '' ), 'getbutterfly_block_categories', 10, 2 );

Marking as solved.

Working fine for me now. Check yours again tmw2591.

If it’s still not working yet, a few other things you can check that could be issues on your end are:

1.) Check WP settings and make sure the site address in wp-admin>settings>general is correct

2.) make sure php-curl is installed and enabled on the site that’s broken (php.ini will tell you)

3.) make sure that you can ping api.www.remarpro.com and the ping times are acceptable (100ms or less)

4.) make sure you can make actually make a secure connection to api.www.remarpro.com
openssl s_client -connect api.www.remarpro.com:443

5.) make sure your DNS resolving is happening properly. (/etc/resolv.conf for linux systems). My setup checks local DNS first, then a caching DNS server I have on my local network, then openDNS servers, and if all those fail I check google DNS servers last. Your setup will be different, but make sure IPs and order are correct.

6.) Confirm # 5 above with:
nslookup api.www.remarpro.com
and/or
dig api.www.remarpro.com

7.) Worst-case scenario (not recommended), you can manually add the IP for api.www.remarpro.com to your local hosts file (/etc/hosts for linux systems).

It could still be some other kind of uncommon server config errors, but if all of that checks out and you’re still getting the error, it very well could be an issue outside of your control like an issue with SingleHop’s network, WP servers, or anything in-between.

• This reply was modified 3 years, 2 months ago by JP3. Reason: fixed small typos

I’ve notified SingleHop and referenced this topic. Hopefully they are able to resolve it soon.

Identical errors on a fresh install.

Speed test for me shows near 100Mbps down 12Mbps up. Check your ping times instead of speeds. My issue was due to excessive ping times, not slow speeds.

EDIT:
Some more info to help. traceroute (tracert on some systems) shows why the error is happening for me (first few sensitive IPs removed):

root@server-hostname:~# traceroute -m 100 www.remarpro.com
traceroute to www.remarpro.com (198.143.164.252), 100 hops max, 60 byte packets
 1  X.X.X.X (X.X.X.X)  0.366 ms  0.449 ms  0.751 ms
 2  X-X-X-X.res.spectrum.com (X.X.X.X)  9.367 ms  9.459 ms  14.750 ms
 3  X-X-X-X.res.spectrum.com (X.X.X.X)  14.888 ms  14.992 ms  15.097 ms
 4  bundle-ether34.orld71-car1.bhn.net (71.44.61.11)  15.232 ms  15.349 ms  15.428 ms
 5  bu-14-tamp20-car1.bhn.net (71.44.1.210)  18.956 ms 072-031-067-217.res.spectrum.com (72.31.67.217)  20.109 ms  19.968 ms
 6  071-044-003-032.res.spectrum.com (71.44.3.32)  19.296 ms 071-044-003-024.res.spectrum.com (71.44.3.24)  13.135 ms 071-044-003-026.res.spectrum.com (71.44.3.26)  14.110 ms
 7  10.bu-ether15.tamsflde20w-bcr00.tbone.rr.com (66.109.6.96)  22.072 ms bu-ether19.chctilwc00w-bcr00.tbone.rr.com (66.109.6.42)  22.177 ms 10.bu-ether15.tamsflde20w-bcr00.tbone.rr.com (66.109.6.96)  24.257 ms
 8  66.109.9.140 (66.109.9.140)  42.846 ms  41.121 ms bu-ether17.hstqtx0209w-bcr00.tbone.rr.com (66.109.1.70)  42.809 ms
 9  107.14.19.49 (107.14.19.49)  42.950 ms ge-3-1-0.cr1.sea20.tbone.rr.com (66.109.6.90)  45.014 ms bu-ether12.dllstx976iw-bcr00.tbone.rr.com (66.109.6.39)  43.630 ms
10  209-18-43-77.dfw10.tbone.rr.com (209.18.43.77)  45.620 ms  46.458 ms  43.522 ms
11  equinix-dallas.dal2.us.voxel.net (206.223.118.164)  44.974 ms  45.145 ms  37.990 ms
12  bbr2.ae7.dal006.pnap.net (64.95.158.202)  38.609 ms  37.352 ms  43.454 ms
13  bbr1-xe-1-2-1.inapbb-chg-dal-1.chg.pnap.net (64.95.158.157)  67.849 ms  66.742 ms  67.610 ms
14  * * *
15  border2.ae2-bbnet2.chg.pnap.net (64.94.32.69)  52.179 ms border1.ae0-bbnet1.chg.pnap.net (64.94.32.4)  53.402 ms border2.ae2-bbnet2.chg.pnap.net (64.94.32.69)  52.196 ms
16  inapvoxcust-lag.border2.chg.pnap.net (64.94.34.70)  54.126 ms  54.013 ms inapvoxcust-lag.border1.chg.pnap.net (64.74.106.114)  54.595 ms
17  agg2.c13.r03.s101.chi03.singlehop.net (108.178.47.245)  53.306 ms agg1.c13.r03.s101.chi03.singlehop.net (108.178.47.247)  46.785 ms agg2.c13.r03.s101.chi03.singlehop.net (108.178.47.245)  47.645 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
31  * * *
32  * * *
33  * * *
34  * * *
35  * * *
36  * * *
37  * * *
38  * * *
39  * * *
40  * * *
41  * * *
42  * * *
43  * * *
44  * * *
45  * * *
46  * * *
47  * * *
48  * * *
49  * * *
50  * * *
51  * * *
52  * * *
53  * * *
54  * * *
55  * * *
56  * * *
57  * * *
58  * * *
59  * * *
60  * * *
61  * * *
62  * * *
63  * * *
64  * * *
65  * * *
66  * * *
67  * * *
68  * * *
69  * * *
70  * * *
71  * * *
72  * * *
73  * * *
74  * * *
75  * * *
76  * * *
77  * * *
78  * * *
79  * * *
80  * * *
81  * * *
82  * * *
83  * * *
84  * * *
85  * * *
86  * * *
87  * * *
88  * * *
89  * * *
90  * * *
91  * * *
92  * * *
93  * * *
94  * * *
95  * * *
96  * * *
97  * * *
98  * * *
99  * * *
100  * * *

I’m in central FL. My packets go to Orlando, then Tampa, then Texas, then a whole bunch in Chicago that either drop the packets or just take so long that my local WP install times out. The www.remarpro.com resolved IP also shows that the WP destination server is also in Chicago and also using the SingleHop network that seems to be the source of the problem.

Nothing we can personally do about it, and perhaps SingleHop should be notified to look into it.

• This reply was modified 3 years, 2 months ago by JP3. Reason: more details to help others diagnose

I just encountered this error as well.

I can’t speak for the others, but after playing around with it, it appears to be a conflict with the plugin ” Advanced Custom Fields: Extended“.

I setup a group and within that group are 3 fields:
cost_per_item (number type)
number_of_items (number type)
total_cost (text type, formula is: cost_per_item*number_of_items )

If that group is at the “top layer”, I don’t get the error message.

If I tuck the group within another layer field type (like a tab or accordion), then I get the error message.

Hopefully that helps narrow it down a little more. If you’re looking for something specific, let me know and I’ll provide you with what I can.

Strange, as long as I manually remove the “https:// ” and “%20” from my entry before saving, it saves properly in my DB. If they are there when I click save then is saves them incorrectly as you describe.

My crude fix of raw editing wassup.class.php will solve it for now. Then it won’t add those extra characters anymore.

• This reply was modified 4 years, 7 months ago by JP3.

Confirmed here too.

Looking through the code, I’m not sure why the https:// is being added to the admin options page, but the DB entry for it shows that it’s saving properly, which I’m assuming means that it will also still work properly (we’ll find out over time.)
DB entry in Options table for option_name “wassup_settings”:

Single IP exclude:
... "wassup_exclude";s:15:"XXX.XXX.XXX.XXX" ...

Multiple IP exclude:
... "wassup_exclude";s:28:"XXX.XXX.XXX.XXX, XXX.XXX.X.X" ...

I looks like we can ignore it, but it is rather annoying.

EDIT: Make sure you take the https:// and %20 out before each save. If they’re in there when you save it, they get saved to the DB too, and it wouldn’t work right.

It appears as tough it’s the “cleanFormText” function being called on wassup_exclude on line 732 in wassup.class.php

A quick fix would be to change:
cleanFormText($_POST['wassup_exclude']);
To:
$_POST['wassup_exclude'];
but this is NOT recommended since it does ZERO sanitation of the input before saving to the DB. If it’s just you and only you using the plugin, maybe you can risk it.

Until the plugin author addresses this, we’ll either have to manually remove the https:// and %20, or write our own sanitation function that only strips unwanted characters without doing any conversion/encoding.

• This reply was modified 4 years, 7 months ago by JP3.
• This reply was modified 4 years, 7 months ago by JP3.