[wp-hackers] What goes in a theme and what goes in a plugin
frank at bueltge.de
Thu Jan 23 20:00:59 UTC 2014
This is so much hepful in this question
On Thu, Jan 23, 2014 at 8:53 PM, Jamie Currie <jamie at wunderdojo.com> wrote:
> Good question. I've got a few big projects that involve a lot of custom
> data -- from meta fields to multiple custom tables. The main functionality
> is used by a number of different clients, all with different themes and
> different needs for how the data is displayed.
> I've opted to go with a hybrid approach. Some data is accessible via
> shortcodes with parameters. A list of accounts that is pulling data from a
> custom table can be used in a page or template via something like
> [LIST-ACCOUNTS type=' ' order=' '] etc. For parameters I try to follow WP
> conventions for functions like get_posts().
> Where possible, data is made accessible to the standard WP system. An
> orders system that is using custom tables ultimately triggers
> wp_insert_post() and adds a new instance of a custom post type. Some
> filters allow any action taken on that order in the Dashboard to update the
> custom tables as well. So then a designer can work with them just like any
> other post.
> You can ensure that a plugin (or multiple plugins) are active via your
> theme's functions.php file. Check out the TGM Plugin Activation class:
> Jamie Currie
> Founder / CEO
> tel: 949-734-0758
> 1840 Park Newport, #409
> Newport Beach, CA 92660
> Master web & app developers
> ------ Original Message ------
> From: "Nikola Nikolov" <nikolov.tmw at gmail.com>
> To: wp-hackers at lists.automattic.com
> Sent: 1/23/2014 11:34:44 AM
> Subject: [wp-hackers] What goes in a theme and what goes in a plugin
>> When I started working in web development, the work process of the company
>> I worked at was to put all of the code for a specific website in it's
>> theme. That means post types, custom fields, theme option interfaces,
>> shortcodes, etc.
>> I was recently introduced to the idea that this is definitely not a good
>> way of creating websites, simply because when the client decides to
>> up the design of their website, they would either have to rewrite the
>> templates of the theme, or painfully extract all of the vital parts of the
>> code out of the theme(or create a child theme, but the themes we were
>> making were not really meant for using as parent themes).
>> Instead you should try to leave only the styling to the theme and have
>> everything else in one(or multiple?) plugins.
>> I agree with that idea, but my biggest question is how much do you put in
>> the plugin and how much you leave in the theme. For instance if you want
>> display some custom data in the theme(in places different than with
>> the_content()), but still have templates(so that appearance can be tweaked
>> from the theme) - do you define some of the functions in the theme, do you
>> just rely on the plugin being active.
>> Let me give you an example. You have custom fields(maybe the plugin you
>> created for the theme is creating them, or it's a third plugin that does
>> that). You want to display the information from those fields in the theme
>> and you want to make them easy to access, so you have a function that
>> returns an array with all of the data. Do I create a function in the
>> that would pull the data(possibly relying on the plugin by using
>> function_exists() to prevent fatal errors), do I just use the plugin's
>> function in the theme?
>> I would appreciate personal experience, as well as references to articles
>> on the topic(or a link to a message on the list if it's been discussed
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers