I cleared the cache. I also ran “Truncate Table session” on the xibo database. I am still seeing the same issue.
Are the permissions correct on the files you extracted? And on the library directory?
Check the log table in the database to see if anything helpful is logged there when you try and log in.
I did last week from 7.4 to 7.7
just copy filesystem 7.7 over file system 7.4 (make backup first please, just in case) by FTP.
Then start local Xibo again as usual and the wizard starts. Answer the few questions and she is rolling again… A bit more complicated then Wordpress update but whole lot better then totally manual…
Took me water fear a few weeks before trying on a test site. Marvellous… There is no button wizard that confused me a while.
You must not just copy over the top. You must always remove the old CMS install and extract fresh.
The reason being that sometimes we remove files as well as add, and if you leave those files there they can prevent the CMS from working. It’s just luck that that isn’t the case between 1.7.4 and 1.7.7
I’m having the same problem but with a upgrade from 1.7.6 to 1.7.7 and I did delete the old files from the Xibo folder and copy the new files. I checked the permissions and made the permissions the same as the library directory but still the same thing. I also cleared the browser cache with no luck. I’m going to have to lookinto truncating the session table as I’ve never done that but I’m just wondering James did you get the 1.7.7 CMS working?
Update*
Okay I have now run the truncate command but that didn’t change anything. After looking at the log table here is error we found when I try to login.
I checked my log file and this is the same error that I get when I try to log in.
Error writing session: SQLSTATE[HY000]: General error: 1665 Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED
Alex,
If I remove old CMS how does the new one know to upgrade with old DB and cachemedia?
We dont want to redo all. Would it no be better to adapt the wizard script to just remove and replace unnecessary and necessary files. I work this way in my other development projects.
Or just adding a readme would be nice… I have done manual migrations but harder for coworkers to copy it. Then they must be bit more fluent and understand XIBO. Lot of people come from wordpress and just want to push buttons…
Anyhow I allways make backups and doubles before playing with fireworks.
@robsmit You follow the instructions in the Release notes (http://xibo.org.uk/manual/en/release_notes.html) which you should be reading as part of your upgrade proceedure - so you know what has changed and any implications for your installation). TLDR, you just replace settings.php from your old installation and it will then know to do an upgrade. There are some caveats.
We support upgrading to 1.7.7 from any version of Xibo. It’s too complex to figure out which files need to be removed each time. It’s trivial to remove the old CMS files at upgrade, so that’s the way we do it.
If you need a single button press upgrade then Spring Signage (and possibly others too) offer that as part of their Cloud hosting offering.
In 1.7.7 we change the transaction isolation level to READ COMMITTED to support running on systems where there is MySQL replication going on. Unfortunately that’s incompatible with setting up MySQL to BINLOG_FORMAT = STATEMENT.
You can change that setting to MIXED in your MySQL configuration and restart MySQL to get things working if it’s appropriate in your environment. If you’re not using a replicated MySQL instance then as far as I’m aware there’s no implication for making that change.
I’ve logged it as a bug to be investigated here:
1 Like
Thanks. I made the change in MySQL and we are able to log into xibo.
I succeeded to 1.7.7 without problems then. Going to 1.7.8. brought other problems.
On different hosters tried. I can not import the sql import of the export of the older runnin 1.74 or 1.7.7 system. Even if I change php time out settings, max file sizes. It results in an error message of XIBO immediately after login or not respondig to correct login data. (pass and user).
During import the connection to hosters (Strato or Hostinger) seems not being completed. However is partly. >> Thus corrupted. The risk of local company firewall ruled out by trying it at home or elsewhere results to same. So down to a non migratable or upgradable XIBO of which I cant figure out why this happens. Any idea? To me cant be XIBO related because errors are in PHP-admin already unless I overlook something?
What error messages do you get?
If your old backups won’t import then that suggests that they weren’t exported correctly. Without having access to them I can’t say for sure.
I can’t think of any reason 1.7.8 would not run where 1.7.7 will. You’d need to provide logs/error messages showing your issues for us to help you further.
I do get error messages like time out and that I need to restart the ipload . But afer several recoonnects will not result in anyting viable .
Said database is aprox 300 MB. We run it on a Strato VPS. Max upload size shouldbe 2G
even if I force the default 2G to 1G or whatever it wont complete. looks like a 250 Mb limit?
Another account is on Hostinger with a 250 Mb upload limit. I cantc chant change max file size there.
When I did a succesfull migration to a shadow and an 1.7.7 ugrade, the database was presumbably smaller then 250 Mb. Nog log files will help, unless you tell which logfile to get where that would indicate anything. Worst strato backups wont become active/valid if placed back, even from the time we had a succesfull shado on the same VPS. refuses to login at proper credentials even.
So to be clear you can’t upload your database backups?
It sounds like perhaps the PHP maximum execution time is set to low. That’s not a fault of Xibo though!
We really don’t recommend running Xibo in shared environments where you don’t have control of the configuration of PHP etc for exactly this reason
No this is a virtual Ubuntu server with Strato, all execution times and file sizes set to max.
Max file size should be 2 Gb. So no shared hosting. Shouldnt be a XIBO problem.
However we are able to perform other wordpress databases without a problem or neighbouring Magento shops! in adjacent sub domains. Until June we had no problem with the XIBO either migrating to shadow environment or restoring a backup.
However designing websites on shared hosting with an other hoster repeatedly gave a similar problem in the longer past where I had other responsibilties in this company.
I’m really not clear what the problem is then?
If you have proper console access, upload your backup file via SSH or similar, and then restore it directly from the mysql command line utility. No need to use a PHPMyAdmin etc to do that.
Solved, definitely a XIBO problem involving stats and logs kept in that database. Kick it clean very continously or don’t use it until this data is logged to a file outside the database… Stat table need be emptied by PHP-admin. No button in XIBO itself to clear the table again. And mind that 250 Mb file size limit or you need to use SSH to do work, which can be cumbersome with some hosters and strict employers… Most shared hosting will limit you right there.
Xibo maintains those records with the maintenance script per your
configuration. If you’re not running it, or have configured high values,
then yes those tables will get very large. Configuration of the maintenance
script is covered in both the manual, and the CMS Post-Installation guide
on the front page of this forum.
The data needs to be in the database so it can be reported upon. Putting it
in an external file is not workable.
If you don’t want or need stats, then you can turn them off directly in
your display settings profiles.
Ensure you CMS is in Production mode and that debug and audit are turned
off, and auditing is disabled on the displays to log only error conditions.
In normal operation, you’ll see few or no logs at all.
Right, running 1.7.8 with new database formate to date. All going smoothly.
Just install a fresh xibo file system latest version in adjacent folder and point it to old database copy.
You will be prompted for a database format upgrade not backwards compatible.
And a message if you want to get rid of install.php. Why do I need to remove install.php anyway?
Dont forget to copy your old xibo cache over the new file system otherwise you will miss some media!!! Youi can not do this when fresh instaaling a new Xibo because the install script wants to see a non existing empty cache directory, hence do it afterwards!