View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0026904||mantisbt||bugtracker||public||2020-04-21 18:57||2020-05-18 16:04|
|Reporter||Crifir Namur||Assigned To||dregad|
|Status||closed||Resolution||no change required|
|Summary||0026904: Imported Database Causing Numerous Issues|
Moved our old MantisBT installation onto a new server and followed the guide to import the databases and certain files. Upon use of the new installation, we get a number of issues. First of which, My View defaults to one user and logs you in as that user. Changing cookie name did nothing, purging caches did nothing, ticking the box for a single IP did nothing. We attempted the installation five times with varying changes, from copying the entire old installation to only connecting to the active database.
Plugins will not install, clicking on the "Install" button does not process the request at all. This makes XML imports impossible to test.
Reporting an issue and then reporting a second issue, among some other random actions, throws APPLICATION ERROR #2800
Green OKAYs across the board during the installation process. We are running PHP 7.3, MariaDB (which was used on the old install), and have a fully functional site aside from the bug tracker itself. We attempted the session_cache_limiter( 'none' ); and session.gc_maxlifetime PHP tweaks to no avail.
|Tags||No tags attached.|
The problems you report seem very strange, but your description is too vague to provide any specific help.
Not really sure what you mean by that. Can you provide more details ? What did you move exactly and how ?
Which guide are you referring to, and what section ? Which files ?
Here are high-level steps for moving a MantisBT instance to a new server (YMMV).
What installation process ? There should be no need to run the installer at all, unless you're also upgrading; but if you are, then I'd recommend to first complete and test the migration "like-for-like" before upgrading.
You may also want to run the admin checks - http://new-server.com/mantis/admin/check/
We recently switched our hosting from a standard plan to a VPS system for extended control over our domain.
The guide followed was the posts in https://mantisbt.org/forums/viewtopic.php?t=20592
Migration seemed to do fine until myself and another developer were on the bug tracker, after which there were errant logins to each others respective accounts simply by going to My View, Report Issue, or really any of the other tabs. The trigger seems to be random, as one moment you could be the other user and the next it'd appear to be your own.
We ran the upgrade as a test, as we had the older version of MantisBT on our site and figured an update may help with any database issues. Additionally I suspected it may show any missing modules or ini settings that would be required.
One thing I did notice was that in the MySQL manager, the charset for the database had oddly defaulted to latin1_swedish as opposed to the system default of utf. This also showed in the admin/check page. Changing this through phpmyadmin did not seem to do anything despite the fail disappearing in the admin/check, and we are still having the issue.
Here's the current admin/check for reference. The only fail left is one that probably shouldn't matter at the moment, although I will make the appropriate tweak to the php.ini setting. The warnings seem to be largely false, as everything already lists as the appropriate value or path.
Alright, somehow I have resolved the errant user switches (unsure what did it, I redid the MariaDB installation and then a mysql_update to check the databases). I also cleared the session and cache data for the entire site.
However I am still having an issue where the project selection does not do anything. Say I go from project A to project B, it just closes the project selection menu and does not actually switch, and switching tabs actually causes them to switch back and forth between All Projects and Project A.
I set $g_show_detailed_errors = ON; but it doesn't really make any difference and nothing is shown.
Good to hear you're making progress.
With regards to FAILs in admin checks, be aware that the process will stop at the end of the section where the first failure occured, so it is possible that some checks were not executed.
About the project selection, does the drop-down display as expected (i.e. like it does on this tracker) ? The list items are plain GET URLs, so clicking one should rjust eload the page with that project selected as default. The default project is a global setting for your session, so it should apply within all tabs (after reload).
I don't expect there should be any, but did you check the browser console for errors ?
Yes, the projects at least display. Nothing appears in the browser console, although by switching back and forth between tabs I did actually notice something more peculiar than I thought.
What seems to be happening is that on My View, it is displaying one of our [OLD] projects, which we tag for archiving purposes when we deprecate it. I have never actually clicked it in my testing, but it is worth noting it was likely the first or second project we ever made on the tracker. I cannot load any of the other projects in the list.
When going to View Issues, the project selection actually works as of writing this. However, all other tabs (Report Issue, Change Log, Roadmap, Summary) all seem to have their own quirks. Report Issue seems stuck on one of the parent projects (in particular, the parent project for that [OLD] project), Change Log appears stuck on All Projects (previously we were able to filter by project), and Roadmap is stuck on the same parent project as Report Issue.
Regarding admin/check, I ran it again after changing the php.ini upload_max_filesize directive to 5m, which made that particular fail disappear. The rest are just warnings. https://i.imgur.com/Db1RHGQ.png
Something to note is that oddly, on my session things seem to do fine in terms of the user account remaining consistent. However my co-developer is still having the account swap issues, so one moment he could be on his account and randomly be signed into mine despite that not being something we configured for.
One thing of note is that I just learned nginx is actually running the site. Previously, I had thought it was just Apache. I have never used nginx before, and I am unsure if it is required for me to accommodate things like MantisBT for that.
I actually somehow managed to solve it.
The issue came from Nginx caching, which in a sense makes sense but it was not intuitive in the slightest.
Thanks for the feedback, glad to hear you managed to figure it out and fix it.
|2020-04-21 18:57||Crifir Namur||New Issue|
|2020-04-22 09:46||dregad||Status||new => feedback|
|2020-04-22 09:46||dregad||Note Added: 0063889|
|2020-04-22 17:48||Crifir Namur||Note Added: 0063893|
|2020-04-22 17:48||Crifir Namur||Status||feedback => new|
|2020-04-22 17:49||Crifir Namur||Note Edited: 0063893||View Revisions|
|2020-04-22 17:49||Crifir Namur||Note Edited: 0063893||View Revisions|
|2020-04-22 17:55||Crifir Namur||Note Added: 0063894|
|2020-04-22 17:56||Crifir Namur||Note Edited: 0063894||View Revisions|
|2020-04-23 22:51||Crifir Namur||Note Added: 0063903|
|2020-04-24 11:33||dregad||Status||new => feedback|
|2020-04-24 11:33||dregad||Note Added: 0063906|
|2020-04-24 17:19||Crifir Namur||Note Added: 0063908|
|2020-04-24 17:19||Crifir Namur||Status||feedback => new|
|2020-04-26 02:31||Crifir Namur||Note Edited: 0063908||View Revisions|
|2020-04-27 17:37||Crifir Namur||Note Added: 0063920|
|2020-04-28 17:48||Crifir Namur||Note Added: 0063928|
|2020-04-29 20:40||dregad||Assigned To||=> dregad|
|2020-04-29 20:40||dregad||Status||new => resolved|
|2020-04-29 20:40||dregad||Resolution||open => no change required|
|2020-04-29 20:40||dregad||Note Added: 0063938|
|2020-04-29 20:41||dregad||View Status||private => public|
|2020-05-18 16:04||atrol||Status||resolved => closed|