[wp-hackers] What goes in a theme and what goes in a plugin

[Nikola Nikolov]

Jamie - yes shortcodes are definitely a good way to go about things. With
the option to use custom templates if the structure is more complicated. I
also like your approach for incorporating custom tables data with the
WordPress posts UI - it's some extra work, but it makes things more
consistent and that's quite important(especially with clients that have a
hard time to do something besides write an article :) )

Andrew - I usually stick to classes as well - it's just much more easy to
use them :) And with a function that returns the global object(the way that
bbPress does it with bbpress()) that gives easy access to class methods.

So, to kind of sum-up things:

 - Bundle the plugin in the theme directory(like under /plugins/plugin.zip)
and use the TGM Plugin Activation in order to display a message to the
user, asking them to activate/install the plugin in order for the site to
function normally. This way even if the user accidentally deletes the
plugin, he'll still be able to restore it.
 - Use plugin defined functionality(obviously not in a way that would break
everything - for instance using a plugin defined function in functions.php
on 'init') wherever is necessary.

Should I still try to avoid fatal errors when the plugin is missing,
despite of the fact that there will be a message asking the user to enable
the required plugin?


On Thu, Jan 23, 2014 at 10:00 PM, Frank Bueltge <frank at bueltge.de> wrote:

> This is so much hepful in this question
>
> http://wordpress.stackexchange.com/questions/73031/where-to-put-my-code-plugin-or-functions-php
>
> Best
> Frank
>
>
> 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:
> > https://github.com/thomasgriffin/TGM-Plugin-Activation
> >
> >
> > Jamie Currie
> > Founder / CEO
> > wunderdojo
> > wunderdojo.com
> > 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
> >> freshen
> >> 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
> >> to
> >> 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
> >> theme,
> >> 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
> >> before).
> >>
> >> Thanks,
> >> Nikola
> >> _______________________________________________
> >> wp-hackers mailing list
> >> wp-hackers at lists.automattic.com
> >> http://lists.automattic.com/mailman/listinfo/wp-hackers
> >>
> >
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>