Lately there is a debate about data portability in WordPress community. Normally I don’t care about this type of discussion on WordPress, until I had a client that uses a theme which contains too many custom post types. On top of that, their old coder modified the theme directly in the theme files without creating a child theme as well as modifying original plugin files.
At beginning of the project, I created a child theme to see if it works fine with the current theme. During that time, I don’t know what’s the fuss about data portability. Perhaps because of my ignorance about this concept, most of the theme-related data was lost in the frontend when switching to the child theme.
I warned about the data loss due to theme change to the client. However, I decided to switch back to the parent theme and stick to it for the rest of the project since the client mentioned that the previous coder already modified the original theme.
At that time while struggling to think of a way to modify the styles without modifying the original theme files despite they were already modified, I remembered the concept of data portability.
Data portability, to me, means to retain the already existing data (such as an installed theme with populated data), manipulating them and adding the new data on the site. It basically is a plugin to add a new layer to the site for adding extra features.
So my WordPress plugin development journey for the client’s website began. This actually was my first very own plugin. Before that, I never wrote a plugin from scratch, just edited someone else’s plugins.
At the beginning, I created two files besides the plugin’s main PHP file: style.css and script.js, and added them to the main PHP file using enqueue_scripts function and hook. The style.css was used to change the look of the site, and the script.js was used to modify the content on the site. I know that I can use add_filter function to modify the content. However, I didn’t know much about the add_filter hooks at that time. Later, I added some more files to the plugin based on client’s requirement.
In conclusion, here are the reasons why you should choose to write a site-specific plugin instead of a custom theme: a large amount of data already populated within the current theme and you don’t want to import duplicated data into the child theme, data created using the plugin will transfer to the new theme whenever the client decides to switch theme. However, there are sometimes that a child theme is better for the site, such as a new site or theme that doesn’t have any theme-related data yet, a simple (no custom post type and no option) theme, and a theme framework such as Genesis Framework.
What do you think? Which is better for a site-modification project, a site-specific plugin or a child theme? Discuss in the comments section below.