Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Difficulties updating database from older version of dotProject (2.1.6>2.1.9) #94

Open
SadBaxter opened this issue Oct 1, 2019 · 6 comments

Comments

@SadBaxter
Copy link

Currently trying to move the dotProject database being used at work from its current old version to a newer one, and I've been having to examine my approach a few times.

Firstly, trying to install a new version of dotproject by having it target the old DB and setting it to write config+db causes a fatal error related to clearing a cache in a temporary directory to eventually show up (ignore that random vardump I put it in there to try and see what was going on)

You can get it to work by either only writing config or doing a clean install and then overwriting the database with a copy of the live one from the old version, but this has caused two other issues to show up.

First is that upon attempting to change user roles causes some errors related to cache clearing to show up, which can be removed by going into system configuration and turning off permissions caching.

Second is that gantt charts refused to work at all, no matter what memory allocation you set it to in system config.

I figured that the database was inheriting some bad configurations from the existing database so I've tried removing the config and config_list table from the old database before attempting to install, and it does actually work, completely bypassing the earlier cache fatal error.

Only problem is that you can now no longer log in at all, all login attempts return "login failed".

If anyone's run into this or similar problems that'd be a huge help. I'm thinking that maybe I need to drop more tables/records from the old database but I'm not sure which ones are ancillary/internal processing tables and which ones I'll need in order for the migration to work exactly the same as it did before.
The solution might be that I need to manually insert from the existing DB into the new one rather than just do blanket copying across, which will take time but if that's the only option It's doable.

@SadBaxter
Copy link
Author

SadBaxter commented Oct 1, 2019

I think it's an issue with the install process and permissions. There's repeated PHP warnings whenever it tries to do assign permissions in upgrade_permissions.php, from lines 135 to 152, which is where it calls add_acl for some user roles (as far as I understand). It seems like it's being passed the wrong variables because it trips errors within gacl_api.class relating to stuff not being handled correctly.

Not sure how this would be fixed in the existing database, where would it be drawing data from for this part?

Edit: Also, it seems like there's no .sql file for updating the database from 2.1.6 to 2.1.7 in the db directory.

@ajdonnison
Copy link
Contributor

ajdonnison commented Oct 1, 2019

The recommended way to do an upgrade is to backup your existing setup, grab a copy of your config.php, overwrite your directory with the new version, copy back the config.php, then run the install - which should detect the situation and do an upgrade.

If the version in the config file is not correct, or you haven't copied across version.php then the upgrade will most likely fail. The upgrade process should work properly even with the devel version between releases, although there can be some edge cases where updates have not been correctly applied.

The problems you appear to be seeing are related to it not finding the PEAR library properly. dotProject comes with a pared down (pardon the pun) PEAR library in the lib directory. The search path should include that directory, however, so I'm unsure why it would be looking in C:\php\pear which it appears to be doing. In base.php we explicitly set the include_path to our own libraries first, followed by the original include path.

What you might want to do is to point your browser to install/docs/phpinfo.php which should give you a heap of information including what the include path is set to. That might at least give us some clues.

@SadBaxter
Copy link
Author

At the moment I'm just testing the new version to check that updating will go smoothly, so I've just been grabbing the latest ver and importing the live database via mysqldump, hosted on my own machine via wamp. I'll see about copying the live version of dotProject and trying the recommended install method, unfortunately we can't run a test parallel with the live server because it runs an old version of PHP and afaik our hosting service charges extra for the tool to run multiple versions simultaneously.

Here's the phpinfo dump phpinfo().zip. Include_path does seem to being set incorrectly and it's probably down to how wamp is configured by default or somesuch.

The solution might be that we need a better ability to test stuff on our host or get a similar environment set up locally, to be honest.

@ajdonnison
Copy link
Contributor

If you install the new version and then copy the old database across, you still need to run the install again as it most probably needs to do updates before the new version code will match the database.

On the phpinfo I've just realised that since it doesn't include base.php first, it isn't going to show the changed include path. Since I don't have wamp it might be a little guesswork involved in tracking down that issue.

For testing I've started using docker images - I plan on having a docker release in the not too distant future for easier deployment. Docker at least gives me the option of completely specifying the environment I intend to run in.

@SadBaxter
Copy link
Author

Apologies for the momentary silence, had to do some other work in the meantime.

Tested with a linux environment but there was no difference in the bugs that showed up, but I did fix the unable to login issue. The config.php needed to be have the dbtype changed from mysql to mysqli after copying over the new version but before running install.php to update, this resolved things somehow.

Gantt charts are still broken but that might be down to the large size of the database itself, even if it's being used with new projects with few tasks. They're not a critical issue to fix currently anyway.

@ajdonnison
Copy link
Contributor

If the gantt isn't showing or is not showing text, it could be font issues. Make sure the lib/ezpdf/fonts directory is writable. Then try it again - it should auto-generate the fonts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants