Jump to content

Graeme S.

Clients
  • Posts

    1,502
  • Joined

  • Last visited

  • Days Won

    1

Graeme S. last won the day on August 31 2010

Graeme S. had the most liked content!

7 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Graeme S.'s Achievements

  1. Ok I have resolved this. I would like to thank you for your attempts to support, but as you point out the Self-hosting option is much more technical, and not something you support. So, the solution for my problem was the following: 1. Snapshot the server, 2. Dump the db locally 3. Download the new files from the client area 4. Run the new files locally (localhost, on a local php server that is) with the old db and see what's going on, tons of suggestions and errors. First of all the engine needed to change to InnoDB to allow for a different way of indexing, plus tons of other db fixes and clean ups. I did write a 10 page manual for our own usage until next time. No place for that here. Also, add the -TESTINSTALL flag when setting it up, but that's all in the manual: 5. Once done, it doesn't work with just uploading the files as they had been changed after the local upgrade 6. Go in to the server and manually delete all folders (except Images, Notes, Upload - your users will thank you) Do not delete via FileZilla etc. It will take forever. I went to the server and used "rm". 6. Upload "fresh" files that you did not use to upgrade your local, this is around 8000 files and will take 2-3 hours to upload. 7. After upload now you need to make a new Nginx configuration by "rebuilding the web app conf" (if you use Runcloud). Something needs to be refreshed and a server restart didn't help. 8. Now, once it's back again, you can run the /admin/ and login, and then use the upgrade feature which works surprisingly well, but takes a while, around 30-40 min. 9. Once done you are good to go. Snap shot again. Bonus points for turning off your forum before doing all this (inside the admin panel), so they users doesnt try to write to your files while you are doing all this. Expect down time of at least 5 hours when doing all this, not counting any mishaps or issues. There you go!
  2. Hi, yes I have upgraded to PHP 8.1 prior to uploading the files.
  3. Ok thanks for your answers. So you are saying that if the files are uploaded properly, then the upgrader will work?
  4. Hi, I'm comparing the databases and so far I can see many differences there. Ie the table ibf_core_members have a different structure, many things has changed name or are added. Can you provide any manual scripts to upgrade the database manually? I have a local setup to compare now, and this is just what I've seen so far.
  5. Hi, yes, but this issue comes before I even start to upload the files, so it's unrelated to any upgrade. I want to make sure the current installation is working first, before I try to upgrade. But to answer the question yes I did try another upload of the files, and that time it just crashed completely, with error 500. Im 1000% sure I replaced the right folders and files, and it was more than 8000 files. I had to revert. The next step is to do a fresh installation locally and see what's being done, we cant risk more downtime. If anyone is a developer and can answer/have some tips, perfect. The default setup is not working as intended, all manuals has been followed.
  6. I reverted it, and it's back to what is was before. I can see that the "Upgrader" behaves the same way before with showing "There are no applications to upgrade". Perhaps we need to fix something before we can move forward? Maybe something "core" is missing in the installation, that makes it not work later either. Do you know where this logic comes from? In the same installation I get the message that we should upgrade to 4.7.14 (which is not working, as it get stuck at database fixes that are irrelevant/not able to fix, even manually, and it gets stuck) (It shows PHP 7 because it got downgraded on the server restore, I will change it before moving forward)
  7. Thank you for your help, but this is all done. It's really a simple instruction - upload the contents of the latest version and place and overwrite the existing files with these new files. That's it. I think there are some things missing in the installation jumps in the code that you are not aware of. I will try a local full installation and see if that can make it work instead. It will take much longer time, but I think it's the only way forward as the instructions provided doesn't go in to any troubleshooting or help beyond the obvious.
  8. Hi, yes I overwrote all the files via sFTP. Yes I have followed the steps in the Install and upgrade instructions, which says the same.
  9. I do get the same issue when trying to upgrade from 4.5.4.2 to 4.7.14. Doesnt matter if I run these queries manually or not, it stays the same.
  10. This url: https://example.com/admin/?app=core&module=support&controller=support&next=1 Visiting this URL will make it blow up, probably because of the auto cache clearing?
  11. Hi, We have followed the steps to manually upgrade the files using sFTP, as the automatic one only suggested SQL that was irrelevant and had no effect, and couldn't move on. Yes, everything is compatible, we are on PHP 8.0. All the system checks etc run. We are upgrading from v4.5.4.2 to 4.7.14. 1. Snapshotting the server 2. Upload all the files via sFTP (took 2 hours) 3. Going to /admin/upgrade = says no application to upgrade Fine, but we still get error messages about that we should upgrade to 4.7.14, so the files are not applied properly 4. I go to the support tab, and enter info in Step 1, so I land on Step 2 BOOM. The server CPU goes up to 200% and the server stops responding. I think it's because, the support system says "Sometimes badly cached data can cause problems. We have cleared all cached data." If it did clear some cache somewhere, well that created a huge load. It did this before, and I waited at that time 2 hours. Still not working. So I had to revert the server, with data loss as a result. How can I safely upgrade from v4.5.4.2. to 4.7.14 without the entire thing blowing up?
  12. Not able to repro but I'm seeing this in error logs: Error: Call to a member function setQueryString() on null (0) #0 /home/ibsurvival/webapps/forum/system/Dispatcher/Front.php(685): IPS\_Output->js() #1 /home/ibsurvival/webapps/forum/init.php(886) : eval()'d code(18): IPS\Dispatcher\_Front::baseJs() #2 /home/ibsurvival/webapps/forum/init.php(886) : eval()'d code(20): IPS\Dispatcher\nexus_hook_frontDispatcher::baseJs() #3 /home/ibsurvival/webapps/forum/system/Dispatcher/Front.php(81): IPS\Dispatcher\nbenhadverts_hook_nbEnhAdvertsFormDispatcherFront::baseJs() #4 /home/ibsurvival/webapps/forum/init.php(886) : eval()'d code(23): IPS\Dispatcher\_Front->init() #5 /home/ibsurvival/webapps/forum/system/Dispatcher/Dispatcher.php(109): IPS\Dispatcher\recenttopics_hook_dispatcherFront->init() #6 /home/ibsurvival/webapps/forum/index.php(13): IPS\_Dispatcher::i() #7 {main}
  13. That worked. Thank you for the great app!
×
×
  • Create New...