1 mcdonnej Jul 16, 2020 02:04
3 mcdonnej Jul 17, 2020 23:59
Looking at i) ii) iii), I think I've done this--one exception, both systems I'm using are local, so I have direct access via my private LAN and am using scp vs. ftp.
Both sites are using 6.11.4. I don't want to try any updates until I verify I can restore from bare metal if something goes wrong. If I get the error on 6.11.7 when the time comes, I'll post screenshots, but essentially, the site just never came out of maintenance mode.
I'm pretty sure the issue is precisely as you describe--the config files aren't pointed correctly. But, my original site was built on top of the demo data, so it doesn't seem that dropping the demo sites tables would work...but I'm a database novice.
I assumed I was missing a configuration setting somewhere, but have checked every place I can think of--httpd.conf, _basic_config.php, _advanced.php, etc.
4 amoun Jul 18, 2020 06:46
Have you noted that there may be the file [umaintenance.php] in the [/install] folder which you can delete to get out of maintenance mode?
https://b2evolution.net/man/maintenance-html
5 mcdonnej Jul 18, 2020 21:23
Yes, I followed the warning in the source code to restore the database prior to deleting the umaintenance.php file. My Production server is running fine, I'm just trying to figure out how to make a complete copy on a new server. One scare was enough.
I was successful finally just copying the entire b2evolution directory and the entire mysql directory, but there were still some things not working right--imap, opcache, REST API, and XML-RPC. So, I realize a "good" backup/restore should've included my /usr/lib64/php, for example, since the LAMP target didn't have the imap or opcache modules installed. Still haven't figured out why the REST API isn't working.
6 amoun Jul 19, 2020 09:09
OK must leave you to it as it is well over my indulgences, but hopefully you will update here when you get the REST API working. All the best.
7 mcdonnej Jul 23, 2020 00:38
Some good news; I figured out the issue with upgrading. I had added a directory under b2evolution in order to let a private group access some files that I didn't want to host as part of the main site. The upgrade hung up when it tried to back up that directory. As soon as I removed that directory, I was able to upgrade to 6.11.7 and then 7.1.5. 7.1.5 also fixed the REST and XML-RPC APIs.
I also found inside index.php where b2evolution is trying to figure out which collection has been requested, but I haven't yet been able to determine how I tell b2evolution to load a specific collection. That will be a longer-term journey, unless someone has a quick pointer.
I did note that 7.1.5 has a different behavior for the site landing page. I built my site using the demo as the initial structure; now after a user logs in, they see the Blog B intro page. (As a hack, I just copied the content from the "not logged in" page to the Blog B page for now.) I will post that question in a separate thread.
8 amoun Jul 23, 2020 09:51
I also found inside index.php where b2evolution is trying to figure out which collection has been requested, but I haven't yet been able to determine how I tell b2evolution to load a specific collection. That will be a longer-term journey, unless someone has a quick pointer.
There are a couple of things to check.
- Under Site > Site settings you should find this
- Ensure that the collection you choose is set up suitably.
Under Collections > Select the collection you have in 1. above and then > Settings > URLs
Hi
I'm not familiar with your server set up so can't relate to that.
So you say "I then tried to restore the b2evolution files and my database. From the page https://b2evolution.net/man/make-a-backup,"
At https://b2evolution.net/man/make-a-backup the three criteria are
i) the b2evolution program files (which includes your site layout, the backoffice, etc.)
ii) the images and other media files you have uploaded into the /media/ folder structure
iii) your MySQL database (which contains all your posts, comments, users, but not your uploaded files/images).
In upgrade and backups i) I transfer the program files by ftp, not auto
ii) media files I leave alone iii) the database by hand using if something doesn't work and I have to backup a version as you did.
My actions would be as above i) ii) iii) to restore 6.11.4
Then I would transfer 6.11.7 manually by ftp and use the install/index.php upgrade. if I had an error again I would manually delete the tables in the database server and transfer a new set of data and tables in case there had been a partial change by going to 6.11.7 and trying to upgrade.
So is the current issue the demo site using 6.11.4?
Then my query would be, if your data doesn't show, then does the config file actually point to your database. If you are seeing demo content then it would appear not to be.
So if that is the case, and you are sure your backup database is the same version, you could drop all the tables in the demo database and import your backup.
You'd best check the database version to be confident.
It would have been useful to have seen a full screen shot of initial error on trying to upgrade to 6.11.7