HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

utility/structure Questions

MrCaspanMrCaspan
edited August 2021 in Vanilla 3.x Help

So Before I update my Forum to 2021.012 I want to make sure everything is in proper order. I have realized that the import tool I used to import my VB forum had butchered a few tables. I did a clean install of 3.3 and compared the tables and corrected any issues. So now i am just double checking that my database structure is correct by using the /utility/structure utility. I know things like

update `GDN_User` `User`
set `Permissions` = ''
where `Permissions` <> '';

update `GDN_User` `User`
set `Permissions` = '[]'
where `UserID` = '20941';

Will always be in there as these are just to clear out the cached permissions for the user and are regenerated if blank but I am also seeing these 3 lines that will not go away no matter what I do

alter table `GDN_UserAuthenticationNonce`
-- [Existing: `Timestamp` timestamp not null default current_timestamp, New: `Timestamp` timestamp not null]
change `Timestamp` `Timestamp` timestamp not null;

alter table `GDN_UserAuthenticationToken`
-- [Existing: `Timestamp` timestamp not null default current_timestamp, New: `Timestamp` timestamp not null]
change `Timestamp` `Timestamp` timestamp not null;

insert `GDN_UserMeta` 
(`UserID`, `Name`, `Value`) 
values ('0', 'stubcontent.record.locale', 'en');

I have verified that these commands have run with no error and I have even tried to run them on the database themselves and no error, the Last command I get an error that a duplicate record already exists. I know I can ignore that but then why does it show up on the list again to run. I just want to make sure everything is copasetic before I do the upgrade again.


Any ideas why these 3 lines stay persistent?

Comments

  • KasparKaspar ✭✭✭

    Afaik the stubcontent is ok.

    Just disable it


    assume rj knows about the timestamp (I do not recall myself) and will reply when he gets to it.

  • Very interesting to know.. Yeah I disabled that plugin and that MySQL statement went away. I am assuming the plugin is not checking properly that the record exists it just tries to throw it in each run of /utility/structure each time as a guarantee that it's there?

  • When /utility/structure is called, each and every structure method of the plugins and addons is called. That stub content plugins structure method calls this lines:

           try {
               Gdn::set(sprintf(self::RECORD_KEY, 'locale'), c('Garden.Locale'));
           } catch (Exception $ex) {
               // Nothing
           }
    


    Obviously there is no check at all. There is really no need for leaving this plugin enabled and I would always advice to disable everything that is not needed.

    I don't remember much about the timestamp message, but there is a GitHub issue for this: https://github.com/vanilla/vanilla/issues/6483

  • ahh okay so it's just brute force to ensure it's there. Gotcha that makes sense as any subsequence attempt to add it to database will not hurt anything. As long as it doe snot matter is all I care :)

    As for the timestamp I love how they just say its working as intended... Again as long as it does not matter is all I care. It can be confusing to end users as they don't know if this is an issue or not an issue

Sign In or Register to comment.