View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0020872 | mantisbt | upgrade | public | 2016-05-03 13:29 | 2017-07-09 05:02 |
| Reporter | joediddley | Assigned To | atrol | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 1.3.0-beta.3 | ||||
| Summary | 0020872: Argument passed to columns_remove_invalid() must be an array, null given, called in... | ||||
| Description | Apologies in advance if I am not following protocol, I'm just a normal user. I tried Rc1 and then nightly build, with same results. Here is what happens: (A) Install.php writes two "Notice" implying twice-defined custom constants (though that is not the case in custom_constants_inc file), where we have these bug additional statuses <?php Maybe there is an "implicit" definition of them from some reference of those custom statues in another file such as bug flow? Since these were in 1.215 custom_constants_inc file they should be acceptable in 1.30, no? I'd be scared to remove these definitions as it isn't clear that would work either, and feels like it could break our mappings and statuses. The install script only had those two messages on the page, and nothing else: There was no other button or any indication it had completed. I don't know if the install script failed after these warnings, or not. Do we have an ambiguous state, I don't know (but should). (B) After (A) above, going to index / my_view_page, I received the crypto warning, which from reading sounded like it was fixed in latest builds, yet it has the same problem and message as the RC1 build. So I manually added $g_crypto_master_salt = '12345678901234567890'; in the config_inc file and that seems to have satisfied it. But then: (C) Now going to my_view_page.php I get this system error message: 'Argument 1 passed to columns_remove_invalid() must be an array, null given, called in [...]/core/custom_function_api.php on line 299 and defined' in '[...]/core/columns_api.php' line 420 Overall, I want to upgrade because I want to be able to export our bug data keeping images and attachments which I understand only 1.3 does, not 1.2. Does anyone want to take a look at this? I can provide you our SSH login info and you can look at our set-up if that would help. I am on a time schedule whereby I am being forced to move our installation to another server, but I don't want to do that without our images in tact. Thank you. | ||||
| Tags | No tags attached. | ||||
|
here are config_inc and custom_strings_inc file (copied from 1.2.15 unchanged). |
|
|
Ummm, finally, can you please block out my DB login info in the file pasted above. Thx :) |
|
|
There have been similar issues, e.g. 0017605. |
|
|
My apologies.. I reported the version incorrectly. The above issue was reproduced with mantisbt-1.3.0-rc.2-dev-master-3709b44.tar.gz |
|
|
joediddley, does running admin/check/index.php give some warnings or errors? The provided information is not sufficient to provide more help in resolving the issue. A complete and detailed description is required for the support team to get a clear understanding of the problem. Provide detailed, step-by-step instructions to reproduce the issue; the additional information listed below may also be useful:
|
|
|
To reproduce: Running admin/check/index.php gives 1 warning and 1 fail: All other tests appear as PASS. Exact version of PHP is 5.3.24. SELECT Version() in MySql returns 5.0.96-log The MantisBT source was not modified in any way. There are some custom variables I previously copied to this bug report. I do not know of any other installed plugins or custom functions. The server is hosted/administered by godaddy for what that's worth. MantisBT 1.2.15 is working fine with the same set up. |
|
|
Let's start with fixing problem (A) I am wondering that your custom_constants_inc.php did work before You do not use any of the constans in custom_constants_inc.php at the moment. Concerning (B)
Concerning (C)
|
|
|
It worked by removing the custom_constants_inc.php file (which, removed the duplicate define ( 'SUSPENDED', 70 ); Hence, these possible issues could use consideration as a result of this investigation: (A) The install script stops cold after providing the message about having a duplicate constant define. But the message looks and sounds like a warning not a failure. The page shows no status as to whether the install completed or not, or what needs to be done next. Suggest some kind of status output is provided there or it is very confusing, may cause support overhead. (B) I thought from bug 0014087 the upgrade would handle creating the salt automatically. But because of the install problem I had in (A) above, I cannot say whether or not the salt actually would have been created for me. (I manually created a salt before the upgrade was successfully run all the way through.) Looking at Bug 0014087 again, it refers to "installation" but not "upgrade". Since the salt requirement is new for 1.3 maybe it should be double-checked that the script will also set it up automatically during an upgrade too. Thank you for the assistance. |
|
|
joediddley, This is not a bug or feature request for MantisBT (you asked for help on how to deal with problems during upgrade caused by your own wrong modifications). I am therefore resolving this issue as "no change required". Please use the forums, the mantisbt-help mailing list or IRC to get support on customizing and using MantisBT (refer to http://www.mantisbt.org/support.php for links and further details).
|
|