View Issue Details

IDProjectCategoryView StatusLast Update
0026904mantisbtbugtrackerpublic2020-05-18 16:04
ReporterCrifir Namur Assigned Todregad  
PrioritynormalSeverityminorReproducibilitysometimes
Status closedResolutionno change required 
Product Version2.24.0 
Summary0026904: Imported Database Causing Numerous Issues
Description

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.

TagsNo tags attached.

Activities

dregad

dregad

2020-04-22 09:46

developer   ~0063889

The problems you report seem very strange, but your description is too vague to provide any specific help.

Moved our old MantisBT installation onto a new server

Not really sure what you mean by that. Can you provide more details ? What did you move exactly and how ?

followed the guide to import the databases and certain files.

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).

  1. shutdown source web server
  2. dump database
  3. copy mantis code to target server (i.e. the whole mantisbt/ directory) as well as attachments (if stored on filesystem)
  4. import database
  5. update config_inc.php if necessary

Green OKAYs across the board during the installation process

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/

Crifir Namur

Crifir Namur

2020-04-22 17:48

reporter   ~0063893

Last edited: 2020-04-22 17:49

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.

Crifir Namur

Crifir Namur

2020-04-22 17:55

reporter   ~0063894

Last edited: 2020-04-22 17:56

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.
https://i.imgur.com/pDZOvAh.png

Crifir Namur

Crifir Namur

2020-04-23 22:51

reporter   ~0063903

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.

dregad

dregad

2020-04-24 11:33

developer   ~0063906

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 ?

Crifir Namur

Crifir Namur

2020-04-24 17:19

reporter   ~0063908

Last edited: 2020-04-26 02:31

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.

Crifir Namur

Crifir Namur

2020-04-27 17:37

reporter   ~0063920

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.

Crifir Namur

Crifir Namur

2020-04-28 17:48

reporter   ~0063928

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.

dregad

dregad

2020-04-29 20:40

developer   ~0063938

Thanks for the feedback, glad to hear you managed to figure it out and fix it.