movieseals

Fixed permissions, disabled firewalld, disabled csf, still same issue. Is there a port I should open to allow connection to the api?

TB is asking my to upgrade modules but when I try to, I get this error: 4 errors Failed to download module "coreupdater" from api server Failed to download module "mailalerts" from api server Failed to download module "statsmodule" from api server Failed to download module "tbphpmailer" from api server

I get the following error when I try to send an email: Failed to send email: SMTP Error: Could not connect to SMTP host. Failed to connect to server However, the SMTP informations are correct. RESOLVED: The issue appears that TLS no longer works, I have to use SSL (and the port that goes with it).

The size of the images is related to your compression setting. The default of 90 is quite excellent. If you it at 100 or more than 90, it will be bigger (slightly) than you jpeg.

No, I meant the Litespeed cache. But the question is valid: should we use the full page cache for TB with Litespeed cache or not?

Wow. Guest view set as Yes is indeed incredibly fast! I used to get the crawler working under 1.3. Have not yet tried with 1.5 - can update you when I do. I managed to fix my issue: the cache works properly with group and logged in mode in 1.5 - it has issues only under 1.3. Really enjoying what was done to 1.5 so far!

Here is my setup.

What about modules? If we upload images from a module that did not necessarily support webp, will TB generate both anyways? I used to be on TB 1.3, just now discovering the features of 1.5. Never used watermark. Trying to diminish my use and reliance on non-native modules as much as possible.

Thank you for the information! The jpg and webp have about a 50% difference in size, in favour of the webp, so no problem so far on that side.

We no longer need to use Imagemagick? First time I hear of this. Any reason why? I just want to understand the logic behind dropping it. I was currently using it to automatically generate webp since my theme did not create them at upload.

With the cache module and all the other caches in TB 1.5, it is quite faster. The only one I am not sure if we can use or not is Full page cache in TB. It does not seem like a typical full page cache, but technically, according to the documentation for the Litespeed cache, it should be off as it may conflict. Other than that, nothing to say except the separate view for mobile in the LS Cache does not seem to work very well. And different views for groups or views for logged or non logged individuals crashes some PS modules. I also noted that vanilla Litespeed was still considerably faster than Apache and even Nginx as Proxy, which is what I had before. And our store was significantly smaller back then. So Litespeed is definitely an improvement for us. I also like Cyberpanel, which is like a cpanel for Litespeed and Openlitespeed. It has its growing pains but now works mostly very well for most usages. It loads quickly and it is pretty versatile and simpler to understand than cpanel.

It was quite a hurdle but I managed to upgrade to TB 1.5 from 1.3. There are still hiccups, mostly with PS modules, but we are mostly there. Now, because I have been doing a tremendous amount of testing, I needed to clear the cache a lot. And being both a blessing and a curse, it does not appear to work like I used to expect it. The new smarty cache menu says it can use the system cache. Which one does it use? APCu? Memcache(d)? Redis? Does it still work if you do not select one of them in the menu below? If so, what cache does it use? If not, why does it not tell you that it will not use the server cache if you do not select anything below? If system cache is used, why are there files generated in the cache folder? Why, even if I delete them (like I used to do when I made changes that would not appear), why are there changes that do not appear yet others do. Stuck in the system cache? But even clearing the cache does not fix them. They eventually clear up much later. I thought it was due to browser cache, but that does not always work either. Anyways, just trying to understand the logic and what it now uses so that I can flush them better when I try new things.

Thank you!!!! That was tremendously helpful!

When I look at the source for my front page, I see a download for this: https://unpkg.com/sweetalert/dist/sweetalert.min.js unpkg is a CDN, and apparently things changed, so this link instead redirects: FROM: https://unpkg.com/sweetalert/dist/sweetalert.min.js TO: 302 And then it loads the new script from the new location, which is: /[email protected]/dist/sweetalert.min.js... Which takes a lot of time for nothing. Not sure if this comes from the theme or TB, but I need to find where this information is sent to the header of the theme, as in the header, all I can see is: {if isset($js_defer) && !$js_defer && isset($js_files) && isset($js_def)} {$js_def} {foreach from=$js_files item=js_uri} <script type="text/javascript" src="{$js_uri|escape:'html':'UTF-8'}" defer></script> {/foreach} {/if} My question is: How do I find which files sends the JS information to the header so that I can correct the link with the proper new destination OR remove it altogether if it is no longer useful? Any help is appreciated. C.

I would absolutely love to as it is a good idea and appears to work very well, but my version of TB is incompatible with Collect PHP logs as I am using 1.3. The reason I am still on 1.3? Several modules that we need to function do not work with TB 1.4 and definitely not on 1.5 for that matter, despite working with PHP 7.4 under 1.3. We also had lots of customizations that are essential to our business - we are slowly moving them to modules, whenever we can, some with our limited knowledge, some we paid fo the modulisrtion but there is a lot to do on that front. We try very hard to minimize the use of overrides and changes to the pages other than the theme itself but it is not always possible. Some modules just straight up stopped working - they are not causing any troubles - they just stopped working altogether. I managed to create an installation of TB 1.5 and I am testing and migrating as much of our current functionalities as I can. It is during that process that I encountered this new issue. Sadly, more stuff will eventually break by the time we have to lockin with PHP 8 and higher.