repair_settings.php issues with 2.1

[illori]

Notice: Use of undefined constant TIME_START - assumed 'TIME_START' in C:\wamp64\www\github2.1\Sources\Subs-Db-mysql.php on line 480

1 | 0.0000 | 392312 | {main}( ) | ...\repair_settings124589.php:0
2 | 0.0002 | 392336 | initialize_inputs( ) | ...\repair_settings124589.php:20
3 | 0.0117 | 405600 | smf_db_list_tables( ) | ...\repair_settings124589.php:381
4 | 0.0117 | 405976 | smf_db_query( ) | ...\DbExtra-mysql.php:243

Warning: A non-numeric value encountered in C:\wamp64\www\github2.1\Sources\Subs-Db-mysql.php on line 480

1 | 0.0000 | 392312 | {main}( ) | ...\repair_settings124589.php:0
2 | 0.0002 | 392336 | initialize_inputs( ) | ...\repair_settings124589.php:20
3 | 0.0117 | 405600 | smf_db_list_tables( ) | ...\repair_settings124589.php:381
4 | 0.0117 | 405976 | smf_db_query( ) | ...\DbExtra-mysql.php:243

https://i.imgur.com/9FhVw4M.png

repair_settings.php does change some of the attachment paths but not all are changed hence causing issues with running the upgrade as the paths cannot be found. the path that is correct is the lower path that has correct status but the top base directory paths are wrong and cannot be changed. even when using the option to restore all settings apparently some are missing.

given in this case i have renamed repair_settings.php but that should not cause this issue.

[sbulen]

This is a dupe of SimpleMachines/SMF#5968

The fix has been applied, the new version must be moved to sm.org.

[illori]

I had used the version from GitHub not sm.org.

…

On Mon, Jan 27, 2020, 10:23 AM sbulen ***@***.***> wrote: This is a dupe of SimpleMachines/SMF#5968 <SimpleMachines/SMF#5968> The fix has been applied, the new version must be moved to sm.org. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41?email_source=notifications&email_token=ABB3G7BXHR324IFTDCRDXODQ7335ZA5CNFSM4KL6PCZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ74SOI#issuecomment-578799929>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB3G7C7CBJV6EY7SGKV26TQ7335ZANCNFSM4KL6PCZQ> .

[illori]

Oh also it does not fix the attachment issue.

…

On Mon, Jan 27, 2020, 10:27 AM Michele Davis ***@***.***> wrote: I had used the version from GitHub not sm.org. On Mon, Jan 27, 2020, 10:23 AM sbulen ***@***.***> wrote: > This is a dupe of SimpleMachines/SMF#5968 > <SimpleMachines/SMF#5968> > > The fix has been applied, the new version must be moved to sm.org. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#41?email_source=notifications&email_token=ABB3G7BXHR324IFTDCRDXODQ7335ZA5CNFSM4KL6PCZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ74SOI#issuecomment-578799929>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABB3G7C7CBJV6EY7SGKV26TQ7335ZANCNFSM4KL6PCZQ> > . >

[jdarwood007]

For the attachment issue, could you get me a copy of the value as it exists in the db before you run the tool?
I won't merge this up onto our downloads site until we have some confirmation here regarding the error.

[sbulen]

You are correct - I didn't get the time_start one... Funny I get no errors, but that definitely needs to be fixed. I think we should wait for the settings changes to settle down before doing so.

I was able to reproduce your attachments issues when there is an issue with the base path used for multiple directories. You are correct: repair_settings.php does NOT fix the base path.

(Note... Looking at your example... Which one is the proper base directory? Either there is none [manual, no base], or, github2.1 is [which has different problems, as Suki points out in the other thread]...

Which approach did you intend to do? Note that in the ACP, you can delete a base by clearing it out & pressing SAVE. You cannot modify a base; you need to add the proper one & delete the incorrect one. So... I believe you can correct your specific issue in the ACP by clearing out all the bases & setting your attachment dirs to be manual, without a base.)

[sbulen]

I won't merge this up onto our downloads site until we have some confirmation here regarding the error.

@jdarwood007 - The existing version does in fact properly address the issues outlined here: SimpleMachines/SMF#5968

I would suggest moving that forward, but can live either way.

Illori raises two additional, separate issues above. Unfortunately, testing is awkward atm due to the settings updates. I think it may make sense to wait for that to settle down before further updates.

[jdarwood007]

Ok. If we feel its stable and that this is a separate issue that needs fixed.

[illori]

the base directory paths are incorrect and not being updated.

which value in the database would relate to this if you need it posted?

[jdarwood007]

Any %attachment% variables in the Settings table. Sanitize any data as needed.

[illori]

attachmentUploadDir
{"1":"C:\wamp64\www\github2.1/attachments","2":"C:\wamp64\www\github2.1/attachments_0","3":"C:\wamp64\www\github2.1/attachments_1","4":"C:\wamp64\www\github2.1/attachments_2","5":"C:\wamp64\www\github2.1/attachments_0","6":"C:\wamp64\www\github2.1/attachments_1","7":"C:\wamp64\www\github2.1/attachments_2","8":"C:\wamp64\www\github2.1/attachments_3","9":"C:\wamp64\www\github2.1/attachments_4","10":"C:\wamp64\www\github2.1/attachments_5"}

attachment_basedirectories
{"2":"D:\wamp\www\github2.1/attachments_0","3":"D:\wamp\www\github2.1/attachments_1","4":"D:\wamp\www\github2.1/attachments_2","8":"D:\wamp\www\github2.1/attachments_3"}

i dont think repair_settings.php is considering attachment_basedirectories. those are the ones not updated.

[jdarwood007]

It does not and thats the reason behind the issues.

[sbulen]

repair_settings.php does change some of the attachment paths but not all are changed hence causing issues with running the upgrade as the paths cannot be found. the path that is correct is the lower path that has correct status but the top base directory paths are wrong and cannot be changed. even when using the option to restore all settings apparently some are missing.

So the problem we're trying to address here is the upgrader?

Can you share a screenshot of the upgrader issue?

[illori]

No. As repair_settings.php did not fix the paths I had an issue with the upgrade.

…

On Fri, Jan 31, 2020, 5:40 PM sbulen ***@***.***> wrote: repair_settings.php does change some of the attachment paths but not all are changed hence causing issues with running the upgrade as the paths cannot be found. the path that is correct is the lower path that has correct status but the top base directory paths are wrong and cannot be changed. even when using the option to restore all settings apparently some are missing. So the problem we're trying to address here is the upgrader? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41?email_source=notifications&email_token=ABB3G7DZIGPYGH3ZE6TWA23RASSHTA5CNFSM4KL6PCZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKQHXOA#issuecomment-580942776>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB3G7CX7IQQX2765GMN7LDRASSHTANCNFSM4KL6PCZQ> .

[sbulen]

Illori - I have spent some time with this, & 2 things...

(1) Regarding the TIME_START and non-numeric value issues reported above - SimpleMachines/SMF#5961 includes fixes for those. I do not get them with that code, so a fix is on the way there.

(2) I cannot reproduce an issue with the upgrader no matter what I put in attachment_basedirectories. attachment_basedirectories is not used in the upgrade process for attachment processing, which makes sense, because it's only used when new attachment directories are being created (to determine the new directory to create). Note there is an attempt to migrate attachment_basedirectories from a serialized string to json, but that's it. It doesn't inspect the contents, just does the migration.

So... I would like to know more about the upgrader issue we're trying to solve here. Screenshots? Was this a 2.0 => 2.1 upgrade? A 2.1 => 2.1 upgrade? Were you trying to run repair_settings before or after copying the new 2.1 code over?

[illori]

I moved my install to a new computer. I ran my normal upgrade from GitHub. After fixing paths.

…

On Fri, Jan 31, 2020, 8:02 PM sbulen ***@***.***> wrote: Illori - I have spent some time with this, & 2 things... (1) Regarding the TIME_START and non-numeric value issues reported above - SimpleMachines/SMF#5961 <SimpleMachines/SMF#5961> includes fixes for those. I do not get them with that code, so a fix is on the way there. (2) I cannot reproduce an issue with the upgrader no matter what I put in attachment_basedirectories. *attachment_basedirectories is not used in the upgrade process* for attachment processing, which makes sense, because it's only used when new attachment directories are being created (to determine the new directory to create). Note there is an attempt to migrate attachment_basedirectories from a serialized string to json, but that's it. It doesn't inspect the contents, just does the migration. So... I would like to know more about the upgrader issue we're trying to solve here. Screenshots? Was this a 2.0 => 2.1 upgrade? A 2.1 => 2.1 upgrade? Were you trying to run repair_settings before or after copying the new 2.1 code over? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41?email_source=notifications&email_token=ABB3G7CRZNS4QYSWQTAFHNTRATCYRA5CNFSM4KL6PCZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKQO45Y#issuecomment-580972151>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB3G7F3GN3CFL6XOJ5SNZ3RATCYRANCNFSM4KL6PCZQ> .