Dirty Butter

Open the Setup/db/Upgrade 6.2.7 and 6.2.8 sql queries files. I usually copy/paste the contents of the sql file in the Query Database tab in admin Maintenance.

I'm not the best one to be trying to help, but I can get some answers from you others can use in helping you. First of all, did you get the error trying to upgrade trying to use the Upgrade from within Admin? Or did you upload the zip of 6.2.8 and extract, then run setup? Is your store stock code, or do you have edits to skin or admin files you don't want to lose? It might help to know what version you are upgrading from. If you are not using stock skin, what are you using?

Thanks, Ian! I appreciate you taking the time to comment. I looked at the gtmetrix.com results. As expected, they are much better than the mobile site results Google goes by. But gtmetrix makes their findings explanations a little easier for me to understand.

That's true! So obvious to you, but didn't even occur to me. So now I need to move on to one of the bigger issues the PageSpeed test complained about - scripts that load before the page will complete, like AddThis (the worst).

WBMP is in the list under PHP info GD, but not webp. So THAT's my problem. My only interest in using webp for these constant top and bottom images was that using webp images supposedly speeds up the site.

Having folders in Filemanager doesn't seem to make a difference. Stock site still refuses to "see" the image in Filemanager, whether I add an image folder or delete it.

I just tried uploading one of my webp images on my 100% stock test site without folders in Filemanager with exactly the same result. It crashed Filemanager completely, since there are no folders, with this error message: classes/gd.class.php:118 - Call to undefined function imagecreatefromwebp() Again in stock, I deleted the image and tried uploading it again from the Images tab in a Product Listing. This time it did not crash Filemanager - the existing images show properly in the Images box - but clicking on the webp image shows the NoImage image.

Thanks for the warning on the image. I will clear my image cache and see what I get. Do you have your images in folders or all in Source?

I tried changing a couple of images to webp format and had unexpected results. I was able to upload the webp logo without a problem. So I then tried to upload newpaypal.webp image, which is at the top of every page on https://plushmemories.com/lovie-shoppe. The upload seemed to "hang". I refreshed the page, but got a white page. I refreshed the browser and was able to open any Filemanager folder except the folder I had uploaded the webp image into. I checked via ftp and sure enough the file was uploaded. I deleted it and uploaded the same file via ftp. The Filemanager folder it was in still crashed on trying to access it. So, I changed the skin to use the newpaypal.webp image and it shows! Just to be sure there wasn't something wrong with newpaypal.webp, I then attempted to upload cubecartlogo.webp (at the very bottom of every page) - with the same crash of Filemanager. To summarize - apparently the logo upload worked properly. The Filemanager upload of a webp image seems to have a bug. (PLEASE NOTE - I reverted to newpaypal.jpg, because that folder has some essential images in it and I did not want issues with the live site. But I left cubecartlogo.webp installed at the very bottom of each page, as nothing in that image folder is crucial.)

A cookie associated with a cross-site resource at https://accounts.google.com/ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032. I saw that looking at the Chrome Developer Tools comments on our site as well. Looks like something CC will need to fix before the next upgrade or maybe now?? Yes, I had to change my Security Settings to allow Social Trackers to get AddThis working again. I thought I had that turned off with an exception for a few sites, like AddThis. I'll fiddle more tomorrow and see if I can find a Custom setting on FF that I like.

What browser do you use?

I use AddThis to add products to Pinterest, Facebook, and Twitter each time I list something new - that was the 24th. So mine is a recent issue. It was working as-is on Chrome, but FireFox required changing my Security settings.

Wordpress install says browser has it blocked, just as Bsmither suggested. Haven't found setting yet, but thought I would give result there.

Mine is gone, too. But I know it was there on the 24th, after I upgraded to 6.2.8.

I figured it out! It dawned on me why it was not observing the "hide" choice. I renamed the code in my accordion.php to use document naming from the SFWS header file already being used, so active in hooks: <ul class="left"> <li><a href="{$ROOT_PATH}" title="{$LANG.common.home}"><svg class="icon"><use xlink:href="#icon-home"></use></svg>{$LANG.common.home}</a></li> {if isset($HEADER_DOCUMENTS) && count($HEADER_DOCUMENTS) > 0} {foreach from=$HEADER_DOCUMENTS item=header_document} <li><a href="{$header_document.doc_url}" title="{$header_document.doc_name}" {if $header_document.doc_url_openin}target="_blank"{/if}>{$header_document.doc_name}</a></li> {/foreach} {/if} {if isset($CONTACT_URL)} <li><a href="{$CONTACT_URL}" title="{$LANG.documents.document_contact}">{$LANG.documents.document_contact}</a></li> {/if} {foreach from=$HEADER_DOCUMENTS_LIST_HOOKS item=list_item} <li><a href="{$list_item.href}" title="{$list_item.title}">{$list_item.title}</a></li> {/foreach} </ul>