Jan Reilink

Hello Support Team,

In my opinion, this is not the way we should have support on WordPress plugins, but if it helps…

Ticket Submitted Successfully!

There is no need for setting up a call, you just need to fix your broken .htaccess.

Here it was Ultimate Blocks too. Took my loss and removed the plugin.

Hi @sanzeeb3 and thank you for your reply.
My question was if your plugin supports StartTLS as an SMTP command (PHPMailer). Not all SMTP plugins do unfortunately.

Fortunately, your plugin does. I was testing a number of plugins, and WP Mail SMTP by WPForms didn’t work either, but in hindsight I ran into some TLS cert issues. I fixed those and your plugin sends e-mail using authenticated SMTP and (Start)TLS.

I’ve marked this as resolved, thank you.

That’s a great idea, Marcelo, thanks. We’ll take it into consideration.

Hello Richard,

Thank you for your support question.

For now, I think you can best disable Vevida Optimizer, as WordPress is adding auto update functionality as well.

We’re considering our options with the plugin, whether we’re keeping it (and updating it to work with WordPress’ Site diagnostics) or removing it.

For anyone facing the same issue: I used MariaDB’s REGEXP_REPLACE function (MySQL has it too).

UPDATE test_posts SET post_content = REGEXP_REPLACE( post_content, '<!-- wp:code -->\n<pre class="wp-block-code"><code lang="(.*)" class="language-.*">', '<!-- wp:code {"language":"\\1"} -->\n<pre class="wp-block-code"><code>');

After this, I had to perform some smaller changes, as not all language names are the same:

UPDATE test_posts SET post_content = REGEXP_REPLACE( post_content, '<!-- wp:code {"language":"csharp"} -->', '<!-- wp:code {"language":"cs"} -->');
UPDATE test_posts SET post_content = REGEXP_REPLACE( post_content, '<!-- wp:code {"language":"visual-basic"} -->', '<!-- wp:code {"language":"vbnet"} -->');
UPDATE test_posts SET post_content = REGEXP_REPLACE( post_content, '<!-- wp:code {"language":"none"} -->', '<!-- wp:code {"language":"plaintext"} -->');

PS:
Gutenberg does not recognize the language when using an alias, e.g if I have <!-- wp:code {"language":"vb"} -->, then editing a post shows Auto-detect instead of VB.NET

• This reply was modified 3 years, 11 months ago by Jan Reilink.
• This reply was modified 3 years, 11 months ago by Jan Reilink. Reason: had to remove backtics for code blocks

@organicaguru @danieljohns , please address your issues to the specific theme and plugin authors. This thread is for GiveWP. The GiveWP plugin authors can’t help you with issues with the Himmelen theme or woocommerce-perfect-seo-url/ and responsive-lightbox plugins.

Thanks.

Hi @kobler,
Thank you for your message. I’m sorry not all database tables were converted. I assume you mean from MyISAM to InnoDB?

The plugin should convert any MyISAM table it finds to InnoDB. And it does so by querying which tables are MyISAM and has a name starting with $wpdb->prefix. Two reasons I can think of are that either the tables that weren’t converted are not MyISAM tables, or its prefix is different.

If this is not the case, perhaps you can enable WP_DEBUG and WP_DEBUG_LOG to see if it logs something related?

@marcanor
A colleague of mine found a solution (one of the sites we host couldn’t get this statement to finish in over an hour and had 290,000+ records): use exists.

delete from wp_yoast_indexable
where exists (
    select 1 from wp_yoast_indexable wyi2
    where wyi2.object_id = wp_yoast_indexable.object_id
    and wyi2.object_type = wp_yoast_indexable.object_type
    and wyi2.id < wp_yoast_indexable.id
);

using where exists() the statement finished in 6 seconds.

Also, it is a MySQL limitation you can’t use a table alias with a DELETE, which is why [table prefix]_yoast_indexable has to be fully written out in the exists clause, instead of using an alias wyi.

• This reply was modified 4 years, 5 months ago by Jan Reilink. Reason: query > statement, code tags around where exists()
• This reply was modified 4 years, 5 months ago by Jan Reilink. Reason: in stead > instead

Hi Donncha, thank you for joining in and your reply. Much appreciated.

Following your advice, and using Simple mode seems to work better. I’ll have to do some extra testing and debugging in de next few days, but a separate cache file is created according to the debug functionality:

$ grep wishlist wp-content/wp-cache-config.php
$cache_rejected_uri = array ( 0 => 'wp-.*\\.php', 1 => 'index\\.php', 2 => 'wishlist', 3 => 'wishlist/*', );
$ grep wpsc_cookies wp-content/wp-cache-config.php
$wpsc_cookies = array ( 0 => 'yith_wcwl_session_15359811dc750423199e6f7bdde9ae51', );

13:07:47 247 /?add_to_wishlist=59016 wpsc_get_auth_cookies: no auth cookies detected
13:07:47 247 /?add_to_wishlist=59016 wpsc_is_caching_user_disabled: false
13:07:47 246 /product-tag/walk-around/page/148/?add_to_wishlist=10403 supercache dir: ABSPATH/wp-content/cache/supercache/www.example.com/product-tag/walk-around/page/148/
13:07:47 247 /?add_to_wishlist=59016 wp_cache_get_cookies_values - found extra cookie: yith_wcwl_session_15359811dc750423199e6f7bdde9ae51
13:07:47 247 /?add_to_wishlist=59016 wp_cache_get_cookies_values: return: f3ac53821a909e42a6e4cce2a7ae2c9e
13:07:47 246 /product-tag/walk-around/page/148/?add_to_wishlist=10403 No Super Cache file found for current URL: ABSPATH/wp-content/cache/supercache/www.example.com/product-tag/walk-around/page/148/index-https.html
13:07:47 247 /?add_to_wishlist=59016 supercache dir: ABSPATH/wp-content/cache/supercache/www.example.com/
13:07:47 247 /?add_to_wishlist=59016 No Super Cache file found for current URL: ABSPATH/wp-content/cache/supercache/www.example.com/index-https.html
13:07:47 247 /?add_to_wishlist=59016 wp_cache_get_cookies_values: cached: f3ac53821a909e42a6e4cce2a7ae2c9e
13:07:47 247 /?add_to_wishlist=59016 In WP Cache Phase 2
13:07:47 247 /?add_to_wishlist=59016 Setting up WordPress actions
13:07:47 247 /?add_to_wishlist=59016 Supercache caching disabled. Only using wp-cache. Non empty GET request. {"add_to_wishlist":"59016"}
13:07:47 247 /?add_to_wishlist=59016 Created output buffer
13:07:47 246 /product-tag/walk-around/page/148/?add_to_wishlist=10403 wp_cache_get_cookies_values: return:
13:07:47 246 /product-tag/walk-around/page/148/?add_to_wishlist=10403 wp_cache_phase2: No caching to do as user agent rejected.
13:07:50 247 /?add_to_wishlist=59016 URI rejected. Not Caching
13:07:50 247 /?add_to_wishlist=59016 wp_cache_maybe_dynamic: returned $buffer

And

13:25:57 223 /?add_to_wishlist=58998 wpsc_get_auth_cookies: no auth cookies detected
13:25:57 223 /?add_to_wishlist=58998 wpsc_is_caching_user_disabled: false
13:25:57 223 /?add_to_wishlist=58998 wp_cache_get_cookies_values - found extra cookie: yith_wcwl_session_15359811dc750423199e6f7bdde9ae51
13:25:57 223 /?add_to_wishlist=58998 wp_cache_get_cookies_values: return: f3ac53821a909e42a6e4cce2a7ae2c9e
13:25:57 223 /?add_to_wishlist=58998 supercache dir: ABSPATH/wp-content/cache/supercache/www.example.com/
13:25:57 223 /?add_to_wishlist=58998 No Super Cache file found for current URL: ABSPATH/wp-content/cache/supercache/www.example.com/index-https.html
13:25:57 223 /?add_to_wishlist=58998 wp_cache_get_cookies_values: cached: f3ac53821a909e42a6e4cce2a7ae2c9e
13:25:57 223 /?add_to_wishlist=58998 In WP Cache Phase 2
13:25:57 223 /?add_to_wishlist=58998 Setting up WordPress actions
13:25:57 223 /?add_to_wishlist=58998 Supercache caching disabled. Only using wp-cache. Non empty GET request. {"add_to_wishlist":"58998"}
13:25:57 223 /?add_to_wishlist=58998 Created output buffer
13:25:59 223 /?add_to_wishlist=58998 URI rejected. Not Caching
13:25:59 223 /?add_to_wishlist=58998 wp_cache_maybe_dynamic: returned $buffer

@yithemes
The only issue now is that the ‘quick-wishlist’ is cached on previous pages and thus not increased / updated (I also tried https://support.yithemes.com/hc/en-us/articles/115001372967-Wishlist-How-to-count-number-of-products-wishlist-in-ajax).

Unfortunately it didn’t produce the expected (wanted…) result for me as well. The number of items in the wishlist isn’t instantly updated on all pages (Ajax is on). I hoped the WP-Super-Cache wpsc_add_cookie functionality would create a seperate cachefile based on the cookie. However, wen using wpsc_add_cookie it adds the cookie to the cache *exclude* list in the .htaccess rewrite condition.

Maybe it’s best to put this support ticket on hold, as I currently don’t have a lot of time available to test and debug this. Or perhaps you can contact Donncha ó Caoimh about how to add WPSC support in Yith WooCommerce Wishlist.

Anyway, to be continued ??

Thanks for your positive reply, @yithemes.

Because it involves a site of one of our customer, this is a possible solution I need to test during a couple of days. I’ll get back as soon as possible, I think some time this Friday.

Thank you for your kind words, Jason!

Thank you for your kind words!

WordPress Version 5.1, wpDiscuz Version 5.3.2 and currently PHP 7.3.2 (yep, that’s cutting edge ?? )

• This reply was modified 5 years, 7 months ago by Jan Reilink. Reason: PHP 7.3.2, not 5.3.2