somePaulo

I guess that for the same reason Post Grid images (set to Default size) went to ‘thumbnail’ size on my client’s site. The theme uses the ‘medium_large’ size for post cards on archive pages by default, but that’s not an option available in Post Grid thumbnail settings. I’ve switched to using ‘large’ images to fix the looks, but would prefer to use the theme’s default size, like Post Grid did before.

Thank you so much! It works.

WPML’s example is not very clear and makes it look like their filter is expecting the actual text name of the field that appears on the user profile page, not the DB name of that field.

Thank you for your suggestion.

I was expecting Relevanssi to pick up string translations from WPML’s wp_icl_string_translations DB table by default. Since it doesn’t, I tried myself, and then asked you when I failed. Ive compiled the code I shared above from Relevanssi (https://www.relevanssi.com/user-manual/filter-hooks/relevanssi_post_author/) and WPML (https://wpml.org/documentation/support/wpml-coding-api/wpml-hooks-reference/#hook-617933) docs respectively, and I’m not sure which part of it doesn’t work. We don’t have access to WPML support since the plugin came bundled with a paid theme, without a separate license needed to get support from them.

I’ve tried your suggestion to determine the post language (see below) and even tried skipping the if statement altogether, leaving just the $post_author = ... line in the function, making sure to rebuild the index after each try. This didn’t help. All our editors are aware of how to correctly publish articles, and they all make sure to set the correct WPML language for posts before they do anything else. I’ve tried creating a new post myself too, but it didn’t help either.

Updated code:
add_filter( 'relevanssi_post_author', 'rlv_translated_author_names', 10, 2 );
function rlv_translated_author_names( $post_author, $post ) {
$post_language = apply_filters( 'wpml_post_language_details', null, $post_id );
if( $post_language['language_code'] == 'ru' ) {
$post_author = apply_filters( 'wpml_translate_single_string', $post_author, 'Authors', 'Display Name', 'ru' );
}
return $post_author;
}

As a workaround, I’ve added the Russian names to Relevanssi synonyms. That works for the frontend search, but might not be a good solution in the long term since we have quite a lot of authors, and the team is expanding (the site is an online magazine), so having to duplicate translations in synonyms is extra work and error-prone.

WPML allows to translate the first_name, last_name, display_name and bio by default, requiring manual intervention to translate other user profile fields. So maybe Relevanssi could check for those four defaults having translations? Or maybe you have some other suggestions I might try?

Thank you!

The option for removing the cache buster query parameter appeared after a re-login. Did that. Flushed all caches. Chrome still misbehaves.

Hi!
Thanks for the suggestion.

I changed the CLoudflareCache configs to use the new cache rules, included the cookies_and_content_security_policy cookie in there, disabled workers mode, and it sort of woks, but still with a weird quirk on Chrome based browsers only.

So, currently, on first load, the cache status is EXPIRED, and after accepting cookies the page gets reloaded as DYNAMIC in Firefox, and everything works. In Chrome & Co., however, accepting the cookies reloads the page as EXPIRED again, still blocking scripts, but hitting the reload button straight after that automatic reload makes things work, loading the page as DYNAMIC with all the necessary scripts.

Enabling the Overwrite the cache-control header option doesn’t change anything. I’ve tried waiting a minute before accepting cookies, but that didn’t help either. Only a browser reload fixes things on Chrome. I wonder if there’s a particular parameter the cookies plugin could pass to force a proper reload…

Also, the cache rules instructions mention removing the cache buster query parameter, but I don’t have that anywhere in my plugin settings.

• This reply was modified 1 year ago by somePaulo. Reason: More details

Thanks for the update @mkvrob

This is to do with cache, yes, since only calls to ‘always allowed’ scripts are cached with the page, and when the cookie is set it doesn’t trigger a fresh fetch of the page from the server. I wonder why this is the case only in Chrome…

Turns out three plugins are loading their own versions of fontawesome. Two of them have copies of the assets in their files, and another one blatantly goes for an @import in its css…

Anyway, this is now solved. Thank you!

Thank you for the detailed explanation and the tips!

The CSP is a caching issue affecting Chrome and clones, but that’s for non-essential external scripts and only happens on the page where you accept the cookies first. Switch to any other page, and everything works fine. I’m trying to find a solution for that, but it’s unrelated to the minified fontawesome files.

The integrity checks must be coming from some plugin or maybe from fontawesome directly. I never set that. I’m actually pulling fontawesome from the cloud. I’ll investigate where these .css files are coming from.

I’ll close the issue when I get this fixed and report back.

Did you find a solution? I’m experiencing something similar.

Only in Chrome and clones, on whichever page you first come to and accept all cookies, the rules don’t seem to get implemented, and scripts get blocked because they’re not in the ‘Always allow’ category. Curiously, if you go onto another page on the site, the rules work. If you return to the initial page via browser history, the rules are still broken. But if instead of going back via history you click a link for that initial page somewhere on the site, than rules work. Firefox and Safari have no such problem, and I can’t see anything different in Chrome’s console compared to FF…

You can try it yourself at https://slimbyapriori.global
It should load a newsletter subscription popup and a FB chat bubble. It won’t, in Chrome, until you do as described above.

For context, I’m using CloudFlare and their cache, with the cookie exception set as directed, and I have allowed the cookies plugin to execute php in its folders. Disabling the cache makes it work. Are there any specific files that I should exclude from caching for the plugin to work in Chrome?

• This reply was modified 1 year, 1 month ago by somePaulo. Reason: Added example link
• This reply was modified 1 year, 1 month ago by somePaulo. Reason: additional info

Thank you!
That’s fixed it. Yay!

Thank you!
That’s fixed it. Yay!

Thank you! It works great now.

Disabling php in uploads seems to do the trick. I still get a not_found page when loading a browser-cached admin page after being automatically logged out, but logging back in again now returns things to normal. I’ll mark this as solved for now. Thank you!

• This reply was modified 1 year, 4 months ago by somePaulo.

Thank you for the tips.

Double checked the .htaccess and regenerated it for good measure. It’s identical to the original one, so made no difference. Double checked apache and php-fpm settings on the server too. All good there. Besides, this has happened to me on different client sites in different hosting environments (both shared and VPS).

Double checked all permissions, and all is fine there. 755 for folders and 644 for files.

Unchecked ‘Disable PHP in Uploads’, will report back when a user gets logged out again and tries getting to an admin page.