Items used by public and admin

[yorkshiretwist]

There's a strong likelyhood that certain items will need to be used by both public and admin views. In the case of classes I guess these would go in "includes", yes?

What about partials. For example if I have a partial that displays a table of data I may want that to be used in the admin area and on a public page, and potentially on posts/pages using a shortcode. Where would that partial be saved so it was clear what the scope of its use is?

[grappler]

Anything shared between admin and public area would be in the includes folder. You could create a partials folder in there.

[yorkshiretwist]

Ok, that sounds sensible. Thanks.

[dashifen]

There has been some discussion regarding the use of a "common" folder with the same or similar structures to the public/admin ones. I've used such a structure at least once. The other way to go is to include common information in the public area because the the public-facing object is included within the admin area, too. This is likely the better way to go if you want to stick with the structure provided by the boilerplate.

On Sat, Mar 22, 2014 at 11:15 AM, Chris Taylor notifications@github.comwrote:

There's a strong likelyhood that certain items will need to be used by both public and admin views. In the case of classes I guess these would go in "includes", yes?

What about partials. For example if I have a partial that displays a table of data I may want that to be used in the admin area and on a public page, and potentially on posts/pages using a shortcode. Where would that partial be saved so it was clear what the scope of its use is?

— Reply to this email directly or view it on GitHubhttps://github.com/tommcfarlin/WordPress-Plugin-Boilerplate/issues/169 .

David Dashifen Kees

[yorkshiretwist]

Using a "common" folder is more, well, common in my experience. Sorry for the pun!

I didn't know that public items were included in the admin area, that doesn't seem very intuitive although I understand it maintains backwards compatibility with the prevuis version.

[tommcfarlin]

The public folder isn't included in the dashboard -- that's what the admin directory is for. public is explicitly for scripts, styles, and partials and views that are meant to render on the public-facing side of the site.

In the next version of the Boilerplate, there will be an includes directory which will be used as a place for shared / common place for items that are shared among both parts of WordPress and also for third-party libraries used across both parts of the plugins.

[yorkshiretwist]

Right, so there could be an "includes/partials" folder? That makes a lot of sense.

[tommcfarlin]

Exactly -- all of that's going to be covered in documentation when we get further into development :).

[qwertydude]

Faced with similar issues of folder structure inconsistencies caused by shared libraries etc, I came here to find to how your are handling it. But am not sure I'm a fan of disjointed includes/libraries

I've started experimenting with an MVCish structure, with more a modern naming scheme - Application, Interface, Data - that makes more sense to me than model, view, controller - which sound like something from the 70s and mainframes. Oh... wait... :D

This is what it looks like at the moment:

+plugin-name
    - plugin.php
    - readme.txt
    + application
        - admin.php
        - public.php
        + data
            + admin
            + public
        + interface
            + admin
            + public
        + assets
        + includes
        + languages
    + documentation

I still need to work on it (and test it in real life!) but I do think a single includes (and possibly assets) folder is preferable in the boilerplate, no matter what structure you otherwise use. Then you don't have to worry about whether they're shared/common or not.