View Issue Details

IDProjectCategoryView StatusLast Update
0026581mantisbtcustom fieldspublic2020-03-10 17:23
Reporterrogueresearch Assigned Toatrol  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Product Version2.21.1 
Summary0026581: Editing custom "bug_print_page_fields" gives "APPLICATION ERROR #100"
Description
  • Go to Manage > Manage Configuration > Configuration Report
  • find an already-existing configuration of "bug_print_page_fields"
  • press Edit button
  • in the new screen edit the "Value" to something new and valid

Result:

APPLICATION ERROR #100

Configuration option "bug_print_page_fields" not found.

If I understand 0022247 correctly, "bug_print_page_fields" was removed?

If so:

  • maybe a database migration should auto-remove existing "bug_print_page_fields"?
  • maybe the error message could be improved to say that that configuration option has been removed?

FYI @atrol : I discovered this due to 0026482.

TagsNo tags attached.

Activities

atroladmin

atroladmin

2020-01-08 17:14

administrator   ~0063401

As a side note:
To get a list of all obsolete options in database, run admin/check/index.php after the upgrade as told in the Admin Guide.
There are some checks for it, see 0013435

rogueresearch

rogueresearch

2020-01-08 23:26

reporter   ~0063402

I've just restored the 2.21.1 admin folder on my prod server and ran admin/check/index.php. It doesn't say anything about bug_print_page_fields.

atrol

atrol

2020-01-09 03:04

developer   ~0063404

As you see in the screen shot, you should get this warning.

Maybe you see some other errors when running the script.
If so, this could be the reason that you don't get the warnings, as the check script stops whenever there is an error.

grafik.png (8,612 bytes)   
grafik.png (8,612 bytes)   
atrol

atrol

2020-01-09 03:24

developer   ~0063405

Independant from that, I am not able to reproduce the original issue in my test installation.
I am able to change an existing bug_print_page_fields entry without getting the # 100 error.

No idea at the moment what's the difference between your workflow/installation and mine.
No time at the moment to have a deeper look.

rogueresearch

rogueresearch

2020-01-09 23:35

reporter   ~0063413

Hmmm, I do have one error, so indeed maybe it stops at that point. I'll see if I can get that error fixed then check again.

MantisChecks.png (77,494 bytes)   
MantisChecks.png (77,494 bytes)   
dregad

dregad

2020-01-10 17:34

developer   ~0063417

I do have one error, so indeed maybe it stops at that point.

Not maybe - that's exactly what happens. The checks are executed by group, and if one group has a failure, then the subsequent ones are not executed at all.

atrol

atrol

2020-01-12 14:13

developer   ~0063428

Waiting for feedback concerning

I am not able to reproduce the original issue in my test installation.

and also the warnings in admin/check/index.pp

rogueresearch

rogueresearch

2020-01-12 14:38

reporter   ~0063429

I've fixed my allow_local_infile warning, that was trivial.

But, from the searching I've done so far, converting a MySQL database from Latin1 to UTF-8 seems non-trivial, especially for a non-SQL-expert like me. But I'll get it fixed eventually, and update to mantis 2.23, and see if I still repro this issue.

dregad

dregad

2020-01-13 02:47

developer   ~0063430

@rogueresearch this may help https://dba.stackexchange.com/questions/123572/convert-mysql-database-from-latin1-to-utf8mb4-and-take-care-of-german-umlauts

rogueresearch

rogueresearch

2020-01-24 12:28

reporter   ~0063514

@dregad, thanks, I found similar threads too. But I haven't found anything as simple as a single command/script to run. I'll get there eventually...

In the mean time, I have updated my prod server from 2.21.1 to 2.23.0, and I do still get the "APPLICATION ERROR #100" error.

I'll report back here again once I managed the UTF-8 conversion too.

atrol

atrol

2020-02-29 11:59

developer   ~0063718

rogueresearch,

You did not provide any new feedback to reproduce the issue; I am therefore resolving this issue as "no change required".

Feel free to reopen the issue at a later time and provide the requested information.