Mikey

@hailite, thanks for the update.

Let me know if I understand correctly:

1) you are going to add a new table in db (for the scheduled image optimization).

2) you are making litespeed-optimize-size postmeta a little bigger by adding one more element in the array.

So, what’s wrong with adding 2 new tables? ??

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

@hailite, well, yes, everybody saves almost everything in wp_postmeta, because it’s the easiest way to go.

But from a true, better, on-going performance perspective, I think a custom table should be used in this case.

Thanks for noting that.

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

@stanleylitespeed, both ??

Sure, I could remove the add/update_post_meta in the plugin’s file and get rid of the unpleasant post_meta on my own, but I am hoping for a different approach from you guys in order to better optimize this (creating a new table or something).

@hailite, I did and it is not working.

I mentioned this several replies above.

Hi @lclarke,

I think you misunderstood me. I was actually letting you know that the info in the commit does not work, because I actually did edit my local copy and tested it.

Hi @hailite,

I know you said that this was going to be in v 3.0, but it was supposed to be a minor change, why wouldn’t you guys fix it in any version following v 2.9.7.1?

Nevertheless, please note that the above solution is not working.

I’ve just tried it on version 2.9.8.5 of the plugin.

It’s a bit awkward how such a small issue can remain unresolved for such a long time.

Because of it, I am still running on v 2.9.7.1 on my live website.

• This reply was modified 5 years, 7 months ago by Mikey.

Hi @hailite,

Thanks for letting us know (I’m still on v2.9.7.1 because of it).

Best regards

@eshook88, nope. And since the plugin author didn’t bother to respond, I deleted it and moved over to something else.

Good luck with it.

Hi guys,

This is still not fixed in v 2.9.8.3.

Basically, the question here is: is it normal to have all those transients stored in my wp_options table, or not?

How exactly do we search for that and where?

(And how come versions of LS Cache prior to 2.8 don’t have this issue?)

Hi @qtwrk,

Thank you, but it still doesn’t make it clear for me.

For instance, it says that However if persistent caching has not been enabled, then the data will instead be cached to the options table.

Well, if Persistent Connection is ON in LS Cache, then why are these transients appearing in my wp_options table?

Another one: Transients are inherently sped up by caching plugins, where normal Options are not. A memcached plugin, for example, would make WordPress store transient values in fast memory instead of in the database.

What am I missing? Is this how it should work? – i.e. storing transients in options table?

What I want is to NOT have transients saved in my wp_options table (which makes it large in size).

Hi Jamie,

I’ve updated and run some tests for a little bit, everything seems to work fine now.

Thank you,
Mike

Hi Jamie,

Thanks for the update.

Does this mean that there’s a 2.1.12 coming out soon?

@qtwrk, thank you for your answer. It’s clear now.

However, I just want to mention that none of my uploaded original-sized images have a .bk.jpg created. Could it be because I only upload images that have already been optimized (thus LiteSpeed having nothing left to optimize)?

Thank you.