• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.
  • Chevereto Support CLST

    Support response

    Support checklist

    • ⚠️ Got a Something went wrong message? Read this guide and provide the actual error. Do not skip this.
    • ✅ Confirm that the server meets the System Requirements
    • 🔥 Check for any available Hotfix - your issue could be already reported/fixed
    • 📚 Read documentation - It will be required to Debug and understand Errors for a faster support response

Upgrading free and/or migrating to v4

Version
1.0.8
PHP version
5.4.16
Database driver
MariaDB
Database version
5.5.68
Web browser
Brave
S

SubnetMask

Chevereto Member
I had been running Chevereto free 1.0 long ago, and recently 'dusted it off' to put it back up for use. I purchased a v4 license and my 'plan' was to migrate what's in the current install to v4. Since, if I'm not mistaken, the free v1 version was a fork of v3, so if that's correct, I'd think there should be a migration path from free v1 to paid v4, even if it's by way of v3. The version I was running was 1.0.8. So the first thing I tried to to was update it from the web interface. That gave me an error 'Can't write into /app/install/update/temp/ path'. There was no 'temp', so I created it and ran chown to fix the permissions and make the permissions path the 'template' folder and then re-ran the update. This time it got further, failing with 'RecursiveDirectoryIterator::__construct(/var/www/html/chev/app/install/update/temp/Chevereto-Chevereto-Free-/): failed to open dir: No such file or directory'. Once again, the folder doesn't exist, so I created it, fixed permissions and re-ran the update. This time it seemed to go ok with no errors, but I get the message 'Chevereto is already installed and updated'. When I went to the dashboard, it was still at 1.0.8, not the 1.6.2 that it was supposed to be downloading.

I also tried updating it manually - you're supposed to be able to download the zip and extract it in the public web folder where the current version is running and that's supposed to update it, but when I tried that, I got:

Warning: dirname() expects exactly 1 parameter, 2 given in /var/www/html/chev/app/loader.php on line 37
Can't find lib/G/G.php

Does anyone have any thoughts on what's going wrong? Or perhaps, is there a way to copy all data from the v1 free install to a new install so everything remains intact?
 
Sort by date Sort by votes
There are several paths, as a general rule of thumb stay away from the web based update as it will mess with your permissions in most systems. If you are OK dealing with that, just take care of chmod the filesystem. If you seek for reliability, override the installation files with the new version. This is, upload the zip file and unzip it in the same filesystem.

Now, you have to understand that filesystem is a completely different layer of PHP versioning (the stuff that runs the software). Chevereto-Free 1.0.8 supports PHP 5 but 1.6.2 works only with PHP 7.4. The error:

Code: 
Warning: dirname() expects exactly 1 parameter, 2 given in /var/www/html/chev/app/loader.php on line 37
Can't find lib/G/G.php

Is because you are using PHP 5, which is not supported by 1.6.2. Since we are there, 4.0.X supports PHP 8 so you also have to take care of that when time comes.

For your case, the safest path is to update the filesystem to Chevereto 3.20.X, switch to PHP 7.4, make sure that the Chevereto-Free database gets properly update and from there, update the filesystem to Chevereto 4.0.X and then switch to PHP 8.

Yes, it will take some time but that's inevitable if you skipped more than 5 years of system updates. There will be also issues with MySQL so if you want to avoid that stick with MySQL 5.6.

In the case this gets out of your hands you can always purchase Extra Support from me, I personally login to your server and fix everything under one hour.
 
Upvote 0 Downvote
Thank you for that information - with that, it makes sense why what 'should work' (unzipping the file to the web directory) isn't working - other dependencies (PHP) aren't properly updated. With this, I should be able to navigate my way to upgrading my existing install to v4.
 
Upvote 0 Downvote
I updated PHP to 7.4 and the old 1.0.8 continued to work. I then tried to upgrade to 1.6.2 (copying contents of the zip file to the root web directory and fixing permissions/ownership) and it blew up (HTTP500), so I reverted and then tried going to the oldest 3.20. I extracted the zip and copied it all up to the web server, but after doing so, I was presented with:

The system has encountered errors in your server setup that must be fixed to use Chevereto:
  • Zip (Zip) is not loaded in this server. Zip is needed to update process.
Where does what zip (I assume chevereto_3.20.13_bc7e6bc4b537.zip) need to go to make it work?
 
Last edited:
Upvote 0 Downvote
Thanks, yes, I finally figured out it was looking for 'php-zip' after getting an error related to it by just going to 'http://MyURL/update', not a specific zip file related to Chevereto.

After getting that installed and uploading the 3.20 files, I got a new result, that being a message that tables needed to be updated in MySQL. When I tried to run the commands, it turned out the MariaDB version I was on does not support InnoDB Full-text indexes. I was running 'mysql Ver 15.1 Distrib 5.5.68-MariaDB, for Linux (x86_64)', and updated to 'mysql Ver 15.1 Distrib 10.6.11-MariaDB, for Linux (x86_64)' (I went to 10.6 because it has an EOL of Jul 2026). After doing this, I was able to run the 'Alter Table' commands and Cheverto reported 'Chevereto has been successfully updated to 3.20.13. You can now continue to the admin dashboard and configure your website.' It seems to be working well on 3.20.

You mentioned issues with MySQL and sticking to 5.6 - Are these issues something that'll randomly show up under certain circumstances, or are they immediately apparent? Or are they MySQL specific and don't apply to MariaDB? I tried to find a 'MySQL 5.6', but generally, MaraiDB tends to get installed when you look to install MySQL (I think that's how I ended up with MariaDB on this install), and while up to 5.5, MySQL and MariaDB share the same version numbers, When MySQL goes to 5.6, MariaDB goes to 10.0.
 
Upvote 0 Downvote
The issue with old databases can be narrowed to the usage of compact rows, which conflicts with the utfmb4 indexes added later on. If you use dynamic rows you won't get that issue.
 
Upvote 0 Downvote
Thanks for that info. I think that should be good at this point.

I originally had a few tables that were compact and was able to change them so all are now Dynamic.

+---------------------+------------+
| table_name | row_format |
+---------------------+------------+
| chv_confirmations | Compact |
| chv_follows | Compact |
| chv_id_reservations | Compact |
| chv_queues | Compact |
| chv_requests | Compact |
| chv_stats | Compact |
| chv_storage_apis | Compact |
| chv_importing | Dynamic |
| chv_likes | Dynamic |
| chv_notifications | Dynamic |
| chv_logins | Dynamic |
| chv_albums | Dynamic |
| chv_imports | Dynamic |
| chv_categories | Dynamic |
| chv_deletions | Dynamic |
| chv_images | Dynamic |
| chv_ip_bans | Dynamic |
| chv_pages | Dynamic |
| chv_users | Dynamic |
| chv_settings | Dynamic |
| chv_storages | Dynamic |
| chv_locks | Dynamic |
| chv_assets | Dynamic |
+---------------------+------------+

+---------------------+------------+
| table_name | row_format |
+---------------------+------------+
| chv_requests | Dynamic |
| chv_stats | Dynamic |
| chv_storage_apis | Dynamic |
| chv_importing | Dynamic |
| chv_likes | Dynamic |
| chv_notifications | Dynamic |
| chv_logins | Dynamic |
| chv_albums | Dynamic |
| chv_imports | Dynamic |
| chv_categories | Dynamic |
| chv_deletions | Dynamic |
| chv_confirmations | Dynamic |
| chv_images | Dynamic |
| chv_ip_bans | Dynamic |
| chv_pages | Dynamic |
| chv_follows | Dynamic |
| chv_queues | Dynamic |
| chv_users | Dynamic |
| chv_settings | Dynamic |
| chv_storages | Dynamic |
| chv_locks | Dynamic |
| chv_assets | Dynamic |
| chv_id_reservations | Dynamic |
+---------------------+------------+

I think I'm going to upgrade to the latest v3 and let it sit for a short bit. Going to v4 might be interesting though due to PHP8 - I was able to install PHP 8.0 on CentOS7, but I think I may need to move to something newer for full and proper PHP8 support as I think there is something newer than PHP8.0.
 
Upvote 0 Downvote
I assume that if I need or want to move this to another server, say something running Ubuntu, essentially, what I'd need to do is get the same version of MariaDB installed, PHP, and the obvious bits and pieces to point the web server, be it apache or otherwise to the right location, then copy the entire contends of the '/var/www/html/chev/' folder and the '/var/lib/mysql' folder to the appropriate locations on the new server and all data should be retained and restored to the new server?
 
Upvote 0 Downvote
If you use the exact same versions then yes, you can proceed as you described. But for databases is always recommended to use mysqldump to handle migrations. This is because packaging could vary, and is safer to use dump/restore so you don't worry about versioning.
 
Upvote 0 Downvote
Rodolfo said:
If you use the exact same versions then yes, you can proceed as you described. But for databases is always recommended to use mysqldump to handle migrations. This is because packaging could vary, and is safer to use dump/restore so you don't worry about versioning.
Click to expand...
Make sure you follow this advice. I got caught up in the past trying to just back up the database folder for a web app and ended up with a fubar website as a result. Mysqldump is pretty easy to use, just read the docs for the version of mysql you are running.
 
Upvote 0 Downvote
You must log in or register to reply here.
Back
Top