ulrichnielsen

Hi Jason, thanks for getting back to me so quickly. I just posted the above message right before you replied.

Actually it might be a false alarm, it does hide the widget on the posts page when this checkbox is checked. However, I wanted to hide it on single posts too, not just on the index page. So I misunderstood the functionality.

Anyways, as a workaround I checked the “hide for all categories”. Only posts have categories assigned to them, so that works.

Maybe in a future version it’d be useful to have a checkbox “hide for all posts”.

Thanks again!

In the meantime I found a workaround, pls consider it resolved.

Sorry, I missed your response, didn’t get a notification.
Thanks for the info, it seems this error message is triggered whnever I update the plugin. Opcache is active on my hosting server indeed. It keeps the data for 2 minutes.
I’m seeing the webp versions of the images, so it’s probably nothing to worry about. Thanks again!

A little update, meanwhile I realized the toggle is added by a plugin and is not part of the default WOO config. So I probably posted in the wrong topic.

Anyways, the question still stands, these two fields should be removed from my checkout page entirely.

Hi @samperrow,

do you have a prediction on when we can expect a per page preloading solution? I’m very interested too, this would be an awesome feature that no other plugin offers. I wouldn’t mind to fork out a few bucks for this.

Frankly, I’m surprised that this isn’t a general demand yet. I was looking for a solution and found none. Implementing preload is easy without plugin, I focused solely on the front page, but then I realised that the preloaded images are there for all other pages, albeit unused. So they trigger a warning. While not a critical issue, it’d be nice to eliminate this too.

Hi @ejcabquina,

thanks for the explanation. It makes sense, I should have thought of dequeueing it amd I probably will do that. But if you have a child theme the fallback is mostly the parent theme css, and I found some classes that were overwritten by something in the main.css even after declaring them in my child theme css, e.g. table properties.

GP is already very good in Lighthouse, compared to other, bloated themes out there, that’s basically the reason why I use it as starter theme. But I’m trying to make it as lightweight as possible.

Thanks anyway!

Hi, my question is related to featured image size too. There’s unfortunately no option to select a size when picking an imgae from the gallery. Therefore the largest size will be inserted which is not the right choice, as it is larger than the container div and is downscaled.

I normally reserve the largest size for lightbox view and don’t want any downscaled images on my site, for performance reasons. Would it be possible to fix this and allow the actual size to be inserted? It is 820 wide in my case. I have the image sizes set up in WP, it is just not considered for featured images.

Hey Johannes, thanks for the super quick response and fix. It’s back to awesome ??

Hi @goaroundagain,

the plugin worked just fine yesterday, then I updated it and now it’s broken. When you click an image it points to the media file directly, no lightbox whatsoever. Can you please undo whatever changes you did in the new release?

I did basically the same but with fewer steps: I just restored a backup of db and file system from two months earlier. Now it’s back to normal but of course I can’t update anything as I have no idea what breaks it (apart from a db cleaner which I don’t have anyway).

Also, in the meantime I went over to WPML and came back. Migration is basically hopeless. Maybe if you start fresh with them, it’s an alternative, but going over while keeping your existing content and site structure intact just won’t work.

It would be awesome to have a patch released, but apparently Polylang team don’t consider this a critical issue. Regarding just this forum, they must have a massive backlog and the focus must be on paid support. So we can only hope they find the time to fix this in the near future.

@chouby,
btw when do you expect to roll out the next update?

Hi @chouby,

thanks for the reply. In the meantime we traded some emails with Sébastien and I explained my situation in detail. The point is that there’s no db cleaning tool installed. I sent over the list of plugins I’m using. But to make it clear to whoever it may concern, here it is:

• Advanced Editor Tools (previously TinyMCE Advanced)
• BBQ Firewall
• Database for WPforms
• Disable WP REST API
• Easy Updates Manager
• HTML Editor Syntax Highlighter
• Hummingbird
• Login LockDown
• Raw HTML
• Really Simple SSL
• Remove jQuery Migrate
• The SEO Framework
• The SEO Framework – Extension Manager
• WebP Converter for Media
• WP Markdown Editor (Formerly Dark Mode)
• WPForms Lite

Also, Polylang has worked nine months just fine, along with all these plugins, and then went south without any tweaks in WP (other than core and plugin updates of course). So if this was a plugin conflict it should have presented itself a lot sooner.

Today I removed Polylang completely, checked mysql for junk and then did a fresh install, with all the other plugins disabled. No joy. As soon as Polylang is activated the error messages show up in both admin and frontend, and no functionality is available.

I did this on a second test site, with the same results. This one has never had Polylang installed previously. I don’t think it’s the expected behavior to pop error messages when you have no languages defined yet, and you just barely activated the plugin.

I see that a new version 3.0.2 rolled out recently, after I reported this, but it doesn’t address the issue. Please look into it.