When to delete a theme created database table?

  • I need a custom database table for my theme and are thinking about what the best practice is in this case when it comes to when it should be created and when it should be deleted.

    There are not very many guides about this. Most guides and tutorials about this topic are about how it’s done with plugins and plugin development. Not themes.

    But this is about a theme. My first thought was of course “It should be created when the theme is activated ('after_switch_theme') and deleted when it’s deactivated ('switch_theme'). But then I realised that that’s not very good. As for with plugins, deleting all data on deactivation is not very good since a lot of people are only temporary deactivating themes and plugins and loosing all data then would be bad.

    So, it should be deleted on theme delete. But I can’t find a hook for that.

    What is the common practice on how to do this?

Viewing 4 replies - 1 through 4 (of 4 total)

  • There is no common practice for it because it’s a very bad idea. The theme should not write any data to the database except its own options, and those options should only be about presentation of existing data. Using an entire database table for theme data is totally not the “WordPress way” of doing things. The theme is all about displaying whatever is in the database, and should be flexible enough to handle all post types (at least basics which can be augmented by plugins). The theme can be switched programmatically at any time, even on each page request, so there should not be data that is only shown by one theme.
    Perhaps what you are thinking of would work better as a plugin? Plugins can add whatever functionality you can think of and style content also. There are also more hooks.

    Thread Starter Peter Westerlund

    (@peter-westerlund)

    Okay. Well, I don’t like to create plugins that is for an in-house purpose and is clearly made for my one theme. It feels wrong too. It feels like plugins are made for third party usage. They can be decactivated and activated. I don’t feel like that is the nature of my purpose. I create plugins for when the feature feels like “a plugin”.

    Anyway, what I wanna do could be done with a custom post type too. But that’s even less the natural purpose of post types;

    1. It’s only gonna be this post list in admin and the edit page. Nothing else. It can absolutely not be accessible from public.
    2. They are not gonna have a “title”. That should be “Name”. And even if there is a way to change the placeholder for “title” I can’t change the field name. And it feels like an ugly hack.
    3. But even worse, the “publish meta box”. This is not something that is gonna be “Published” with a “Publish” button and be able to be a “draft” or “private” or anything. It’s gonna be “Saved” and that’s it.

    So I’ve learned that these kind of things should have it’s own database table. But maybe there are different schools. Of course I wanna do it the “WordPress” way. But if there isn’t yet a “WordPress” for this kind of feature then I have to do something else. Not developing it is not an option.

    But yeah. I guess you mean that just making it a “plugin” IS the WordPress way. Well, maybe I have to consider that. I just felt that plugins are for those who can’t code the feature themselves. I can code, so I can make all features built-in to the theme so I don’t need to see that long and ugly list of plugins. And it will be more neat for the users that are not developers too.

    But maybe I have to re-think the purpose of plugins. I just wish the plugins could belong to the themes somehow so you’ve got that “package” experience.

    I guess you mean that just making it a “plugin” IS the WordPress way. Well, maybe I have to consider that. I just felt that plugins are for those who can’t code the feature themselves.

    Yes and no.
    You have a skewed view of what the theme is for and what a plugin is for.
    The theme is simply for presenting the user’s content on the front end. Period.
    The plugins are for providing functionality that WordPress doesn’t provide.
    It has nothing to do with who can code and who is third party.
    They are all independent, and can be active or not at any time, and that is the WordPress way.

    Be sure to consider what the course of action would be if the site had a hack in the theme. Could you switch themes while you recover and disinfect the site? If not, that code should go in a plugin.
    Can you use the Customizer to preview the site with another theme and see all of the data? If not, that code should go in a plugin.
    Can you easily implement your feature on another client’s site with a different theme? If not, that code should go in a plugin.

    Thread Starter Peter Westerlund

    (@peter-westerlund)

    You are right. And I mean, I know what a theme is and a plugin.

    And that theme of course is about the presentation. But yeah I thought it was ok to have functionality there too.

    I don’t think my view is thaaat ”skew” though. And I think a lot of people and businesses are having a lot of non-presentation relatet functionality in their themes.

    Well I’m happy for your answer anyway and cleared view of this. I will make it a plugin then. And thinking about if I wanna make a new design in the future makes it very logical to have all features outside of that.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘When to delete a theme created database table?’ is closed to new replies.