XF 2.0 Can the uninstaller interact with e.g. entities before uninstalling the add-on?

[Komposten]

I need to make changes to some entities before the add-on is uninstalled. Can this be done from the Setup class, or should I add a "Reset"-option to the add-ons options and have users press that before uninstalling?

 

[S Thomas]

Why not do that in an uninstall step?

 

[Komposten]

Why not do that in an uninstall step?

That's what I was thinking, but I wasn't sure how.
Though I just realised that I should have access to XF\App and XF\Db in the uninstall step, so I guess I could use those to update the database/entities?

 

[S Thomas]

Yea, you would use the schemaManager though.
https://xenforo.com/xf2-docs/dev/lets-build-an-add-on/#some-final-loose-ends

 

[Komposten]

But the schemamanager only allows altering of the schema, not changing actual values of fields in the database.

 

[S Thomas]

Rethink your design if you have to change stock values. Other than that, yea, you can use $this->db(). But really, what is your use case that you need to change stock values?

 

[Komposten]

The add-on changes the authors of posts in certain areas. I'm considering having it change back to the original authors when it's uninstalled, thus I would need to change values.

 

[S Thomas]

... so you're storing the original authors somewhere. Why not store the new authors in a separate column and show them instead of the original authors? Just don't touch the original authors then.

 

[Komposten]

... so you're storing the original authors somewhere. Why not store the new authors in a separate column and show them instead of the original authors? Just don't touch the original authors then.

But in that case I would have to override every template ever that uses the author of a post, wouldn't I? (E.g. actual posts in a thread, thread creator and latest poster in thread listings, recent poster in New Posts, latest poster in the forum list, etc.)

(Sorry if I'm asking stupid questions, but I'm quite the noob at all this.)

 

[S Thomas]

Copy the column on addon install. Rename one of the identical columns to _bkp. Keep using the other column. Delete the column on uninstall, rename _bkp back to original.
How are you even doing it right now?

 

[Komposten]

How are you even doing it right now?

Since the add-on tutorial is all I've had to go on I've used a similar approach. xf_post has an additional boolean column called "komposten_anonymiser_anonymous", and then I have a separate table where I store the original user and the time of the user change (similar to the tutorial's demo_portal_featured column and demo_portal_featured_thread table).

That said, I don't currently have any implementation for changing back the users on uninstall as I wasn't sure how to do it.

Copy the column on addon install. Rename one of the identical columns to _bkp. Keep using the other column. Delete the column on uninstall, rename _bkp back to original.

Gah, I feel so stupid now for not thinking about that!
In that case I'd just have to populate the _bkp column with the original user of new posts as they are made, which should be simple enough.
Generally speaking, is it better to create a separate table to store the add-on's data in, or to add columns to the existing table (xf_post in this case)? Or does that depend entirely on the nature of the add-on, amount of new columns, etc.?

 

[S Thomas]

That said, I don't currently have any implementation for changing back the users on uninstall as I wasn't sure how to do it.

I would do as above and change all templates. That's what template modifications are meant to be used for after all. It's quite a bit more work, but oh well.
Another option could be to hook into the templater_x events and swap out $user->username or something like that in the templater params. That would probably work pretty well I assume
Lastly, you could extend the controller functions which return the $user object into the view. Wrap that function with a ::asVisitor() and use your dummy user for that.
Everything better than modifying the stock data.

Generally speaking, is it better to create a separate table to store the add-on's data in, or to add columns to the existing table (xf_post in this case)? Or does that depend entirely on the nature of the add-on, amount of new columns, etc.?

Pretty much that. My stance on that topic: https://xenforo.com/community/threa...tory-sessionactivity-php.148510/#post-1258829