Petter

mod_xx mostly refers Apache. I normally use Nginx and have very good experience using https, brotli and pagespeed so my recommendation will be to combine these three. I think brotli will do the compression for you so you don't need mod_deflate,,,, but I might be wrong. mod_http2 mod_brotli mod_pagespeed

Can Google Ads webhook integration be done with Thirtybees ? Google: Set up a webhook integration for a lead form extension

When testing a default installation of Thirty Bees, using Google Chrome Lighthouse, there are 9 warnings regarding Trust and safety: Bootstrap@3.3.7 - 5 medium Vulnerabilities IQuery@1.11.0 - 4 medium Vulnerabilities. Please see attached screenshot. Any recomandations ?

What about hosing your own small server ?? - If you have access to a fiber internet access, you can also be your own hosting provider. Let a hosting provider handle your email (to complicated for to do your self safely without some experience and knowledge) and get your registrar to forward the domain to the IP of the fiber line. Any hardware built in the last 10 years will be sufficient to host a "pretty low volume site", if running Debian/ Ubuntu Linux or similar. Even the new Raspberry Pi 4 with 4 or 8 gb memory are quite capable to host a small site if equipped with a SSD like the Samsung T5. And believe me: If a solution like the raspberrypi4 suggested above is not sufficient, or you fear poor performance, you have a luxury problem, since the raspberry4 8 GB version with SSD is a quite capable small solution for hosting a thirty bees website.

When testing a default install of Thirtybees 1,3 (updated with core updater), using Chrome Lighthouse, I get 1 warning about insecure request and also that 9 vulnerabilities is detected, namely Bootstrap@3.3.3 and jQiery@1.11.0 the site is correctly configured for https and http2, using Let's Encrypt and is redirecting all traffic to https, nut still somwhere a http link is trying to load ,,,, See attached image.

Many thanks, I commented out line 117 in /modules/productcontact/views/css/jquery.fbox.css, and now it is working as intended. The problem seems to have been introduced by the produccontact module from FME modules.

I have a "test" site up, running a default install of Thirtybees 1.3.0-main updated to bleeding edge with core updater. When looking at product images, the image is "cut" on the left and right side, leaving only the middle of the image fully visible. See link: http://valifest.com/en/coffee-and-tea/tea/tea-cans The site is running on a Raspberrypi4 - Ubuntu server 64 bit and nginx version: nginx/1.19.10 - PHP7.4 any one out there have a clue about what's wrong ?

It is not everyday you see someone that seems to understand these key factors that Jollyfrog pinpoints. For all of you interested in getting good ranking, take note of these very important advices and implement all of them before trying other measures.

I'v just tried your link, using Vivald, Firefox and Chrome browser - can confirm that the product pic on the product page does not work in any of these browsers.

Fail2ban will solve this problem. Also, not using Fail2ban to protect again brute force login attacks, your site will be hacked - sooner than later. https://www.fail2ban.org/wiki/index.php/Main_Page

When viewing: catalog->product->images no image thumbnail is shown, but when clicking on the image box for preview of the image, the image pops up and displays correctly. Images displays correctly in the shop. php7.4 / nginx / ubuntu

I'm migrating my website from Prestashop 1.6.x to latest Thirtybees and the site now more or less works using the migrated Default Bootstrap theme. From the back office, I can see all categories listed and can also see all category thumbnails in the list. I'm only using category thumbnails, and the thumbnails that exist from Prestashop and is on the server is in size 125x125 pixel I really want to use only category thumbnails for most of the categories since I only want to display Category Cover Image only for some categories. after a lot of googling, I found that Thirtybees when displaying categories is using the Category Cover Image to generate the category thumbnail image, and will not display category thumbnail if the Category Cover Image does not exist. All my category thumbnails is already available at the server and displays correctly when viewing categories form the back office. What I want is to display the category images correctly also when listing categories in my shop, even if Category Cover Image does not exist. I have a few categories using Category Cover Image and for these categories the category thumbnail is displayed correctly (well really not, the category cover image is 870px x 217px and when rescaled by Thrtybees to 125x125 the image is not that nice,,) So I want to be able to only display the category thumbnail, and if a Category Cover Image is uploaded, it shall not be used to generate the category thumbnail since the format for these images most time is quite different.

Before starting the migration, I used CloneZilla to make a mirror of the hard drive so it was easy to revert and start from the beginning. This time I will do all testing on a separate server and move to the live site when finished avoiding downtime for the website. It seemed that all files in the root folder of the website was owned by root and not www-data. It is clear that the thirty bees migration module does not a proper job to check permissions before if gives "green light" to start the migration. I have now done: Before starting for the second time, I did change ownership of all files and directories to www-data sudo chown -R www-data:www-data /var/www/myshop and then: find . -type f -exec chmod 0644 {} + find . -type d -exec chmod 0755 {} + After doing the above, the migration was sucessfull.

And now it's not possible to login to the site, only ting that works is the "We'll be back soon." site in maintance mode,,,

Hmmm, the upgrade is not going well,,,, Backup files in progress. 633 files left All files saved. Now backing up database Database backup: 142 table(s) left... Database backup: 142 table(s) left... Database backup: 56 table(s) left... Database backup: 56 table(s) left... Database backup: 56 table(s) left... Database backup: 56 table(s) left... Database backup: 56 table(s) left... Database backup done in filename v1.6.1.7_20201022-162956-5814a271. Now moving aside incompatible modules... Deleting now obsolete modules... Now preparing the database... Now upgrading files... 9749 files will be upgraded. 9149 files left to upgrade. 8549 files left to upgrade. 7949 files left to upgrade. 7349 files left to upgrade. 6749 files left to upgrade. 6149 files left to upgrade. 5549 files left to upgrade. 4949 files left to upgrade. 4349 files left to upgrade. 3749 files left to upgrade. 3149 files left to upgrade. 2549 files left to upgrade. 2237 files left to upgrade. Restoring files ... Unable to extract backup. Errors File ******admin/autoupgrade/backup/auto-backupfiles_V1.6.1.6_20160922-021700-5f4a2e5a.zip (size: 40971277) has been skipped during backup. File ******admin/autoupgrade/backup/auto-backupfiles_V1.6.1.6_20160922-021958-3f485469.zip (size: 40991287) has been skipped during backup. File *********admin/autoupgrade/backup/auto-backupfiles_V1.6.1.6_20160922-022253-30189bfd.zip (size: 40991287) has been skipped during backup. File tools/geoip/GeoLiteCity.dat (size: 21933406) has been skipped during backup. Error while copying from /var/www/********/*******admin/psonesixmigrator/latest/index.php to /var/www/******/index.php Error when trying to upgrade file /index.php. Actual filenames id replaced with ****** The problem could be a permission problem ? - but the upgrader found some permission problems when starting the upgrade, all these was fixed so the upgrade could continue. After a short while, even more permission problems ( not detected by the upgrader) occurred and the upgrading was aborted and had to be restarted - these permissions was fixed and the upgrade could continue. Now,the upgrade crashed just before finished, and the restore operation failed.,,,

It was also a lot of other folders that missed write permissions, but the upgrade module did not warn about these first, they showed up when starting the upgrade process, so the upgrade process aborted several times and I had to change to write permissions on several folders before the upgrades continued. I choose to do backup of the images also, so the backup progress takes long time, but the progress is ongoing now. To have the possibility to revert if this process fails, I did before starting make a full Clonezilla image of the server so it can be reverted quickly if I get serious problems under ways,,,

sudo apt-get install php7.0-zip sudo service nginx restart Will enable php7.4 when upgrade is done,..,

I'm trying to upgrade a site from Prestashop 1.6.1.7 to Thirt bees using the thirty bees migration module, and when doing so, I get the following errors: thirty bees test suite passing Test 'ImgDir': File /var/www/xxx/img/bg_bt.gif is not writable. Test 'ModuleDir': File /var/www/xxx/modules/report.html is not writable. Test 'MailsDir': File /var/www/xxx/mails/en/forward_msg.txt is not writable. Test 'Zip': fail So, today, the owner and grout of these folders is www-data - what will be the correct permissions for these folders, and should they changed back after upgrading ? Test 'Zip': fail ? How to correct ?

I have seen this Chinese spam before. If running on a Linux server, this spam is easy to block with Fail2Ban - no need for special modules - just write a plain jail config for Fail2Ban

I also nothed this error in the "advanced parameters" in the admin menu tat TLSv 1.2 was not available, even SSL labs showed TLS 12V support. Anyways, this erroe in the admi panel was goen - mostly due to some sytem apt upgrade ??

I would like to also use Word Ops to install ThirtyBees https://docs.wordops.net / and / Or use the word ops stack for running ThirtyBees. I have tried to install ThiryBees on a wo created site, running the Thirtubees instalatiuon wizard. This wizard runs fine, I can start te wizard, etablish contact with the database, suscssfully finalize the install wizard, but when I try to open the homepage / admin page of the new instalation after the wizard is finalized, I get just a blank page without any content. Also, I have tried to look into the nginx and php7.3 error log, but no errors there. - is there some obvious thing to change to make ThiryuBes run on a WO stack ?? - any other out there that might have some input ?

Miss spelling - corrected the post above to PHP7.4,,,,,,

PHP4 is "the next" Ubuntu 20.04 is now released with PHP7.4 as default and I think most folks doing a new installation of Thirty Bees might consider Ubuntu 20.04 server to be used as operating system. From a Thirty Bees perspective, PHP7.4 compability should be considered high priority. 🙂

Bump What is the current status for Thirtybees vs PHP 7.4 ? ? Any knowledge out there ?

I also wrote "Ubuntu 20.04" so it mus be obvious thant I meant PHP 7.4