Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Templates folder #1429

Closed
tobeycodes opened this issue Apr 17, 2015 · 21 comments
Closed

Templates folder #1429

tobeycodes opened this issue Apr 17, 2015 · 21 comments

Comments

@tobeycodes
Copy link
Contributor

This folder structure is way better than having a bunch of files in the root with markdown, bower, etc. What do you think?

templates/
│   404.php
│   page-home.php   
└─── partials/
    │   header.php
    │   footer.php
└─── layouts/
    │   base.php
    │   base-home.php
@tobeycodes
Copy link
Contributor Author

For reference, I learnt about it here: https://github.com/dxw/govsite/

@tobeycodes
Copy link
Contributor Author

The only issue I see, is that when you move functions.php it won't be able to locate_template the /lib files since WP updates TEMPLATEPATH value to theme/templates folder.

@QWp6t
Copy link
Member

QWp6t commented Apr 26, 2015

For the record, i love the restructuring ideas implemented in govsite. Kudos @dxw.

@tobeycodes
Copy link
Contributor Author

@QWp6t I would happily implement and submit a pull request myself but I think we need to discuss what to do with functions.php. We have three options I can see

  1. Replace locate_template with a function to check if the file exists and move to templates folder
  2. Keep functions.php outside template folder (although I'd rather keep all PHP together)
  3. Move functions.php to lib folder and rename to loader.php, and have a functions.php inside the templates folder that loads the single loader file.

@retlehs
Copy link
Member

retlehs commented May 7, 2015

would love to do something like this. it's time to start [publicly] talking about next steps regarding PHP in the theme.

if we are going to be adding functionality like this, it would ideally be managed outside of the theme itself. the best solution is probably to add composer to sage. that unfortunately would bring our package manager count to 3 - npm, bower, and composer.

by adding composer to sage we could also separate the following components into their own repos/projects:

  • the theme wrapper
  • conditional tag check

related reading: http://tomjn.com/2014/04/01/theme-composition-vs-frameworks/

we've discussed this quite a bit internally but haven't made any decisions yet.

@retlehs
Copy link
Member

retlehs commented May 7, 2015

playing with this right now...

wordpress requires functions.php, style.css, and screenshot.png to belong in the subdirectory with the primary wordpress templates (index.php, etc). it would be odd to have those files in a dir called templates/ when they're not actually templates

@tobeycodes
Copy link
Contributor Author

Yeah I know. That is why I didn't actually do anything or submit a pull request.

@retlehs
Copy link
Member

retlehs commented May 7, 2015

seems like we could modify the theme wrapper and also use a utility like #1414 to replace get_template_part to get this working without the weird theme file requirements

like i mentioned in my previous comment, this is going to require us adopting composer in the theme and separating out components.

@JasonTheAdams
Copy link

You know, over time I've found myself favoring what I call "View Functions" over partials. These are functions that I define with the intention of using throughout my templates, something like get_the_billboard. The reason I largely prefer functions over a simple include is because I can pass arguments to the function to tweak it from one section to the next.

You could, of course, rely on the fact that the included file will inherit the current scope of variables, but I find this to be confusing at best -- when viewing the partial I exclaim, "Where the heck did that variable come from?!"

I realize this doesn't exactly mean that the idea of the suggested feature is a bad one, but I felt I'd throw out there that this isn't something I personally miss as a feature, as I think there's a generally better alternative.

@christianmagill
Copy link

@JasonTheAdams, The get_component function mentioned above, #1414, is essentially a "view function" without being tied to a specific item. The first parameter to the function is a component name and the second is an array of arguments to pass to the component files scope.

@retlehs Theme composition sounds really interesting!

@christianmagill
Copy link

Any updates on this? I'm starting to play around with the idea of using a "Get" namespace, which includes functions to load a "part" or "component" with the folder paths built in. I am unsure as far as the regular templates "404.php", "page-home.php", etc. I'm guessing that would require hooking into some WordPress filters to override the deafult.

@kalenjohnson
Copy link
Contributor

Just found this on core trac: https://core.trac.wordpress.org/ticket/31475

Don't know how much interest is in that ticket, but it would simplify how we have set up templates in Sage.

@christianmagill
Copy link

Yeah, I don't count too much on anything getting through WordPress core process. I have seen too many good ideas abandoned, even some added and then removed.

@jessicahawkins3344
Copy link

I have fiddled around with different product structure pretty extensively - and I do think it is a must! @schrapel 's example was a good start. - For someone like me who really uses this as a leaping pad, I'd love to see more lib folders or quicker, easier ways to integrate them into the theme.

I, too, have a lot of template "parts" but don't always want to shove them all in the same folder. Some are page specific, others post specific, and others app integration specific and folder organization is huge for me! :-)

I should start fiddiling with that again and maybe share some quick solutions, see what I can do!

@retlehs
Copy link
Member

retlehs commented Oct 13, 2015

would love to know more about how some of y'all might be handling this right now

@retlehs
Copy link
Member

retlehs commented Dec 19, 2015

going to close this out as @QWp6t has solved this issue in the upcoming sage 9 (more info soon).

check out the folder structure in both the theme root and the templates directory: https://github.com/roots/sage/tree/sage-9

@retlehs retlehs closed this as completed Dec 19, 2015
@retlehs retlehs mentioned this issue Dec 19, 2015
9 tasks
@mtx-z
Copy link

mtx-z commented Jul 17, 2018

From what I see on Sage 9.0.1 and latest WP 4.9.7:
TEMPLATEPATH & STYLESHEETPATH templating variables (see wp-includes/default-constants.php wp_templating_constants()) are directing to the /resources/ folder.

It make my woocommerce look for a woocommerce.php into /resources/ instead of /resources/views using TEMPLATEPATH variables.

Shouldn't TEMPLATEPATH be /resources/views ?

Thanks !

Note: for improving https://github.com/mtx-z/Sage9-Woocommerce-Integration

@knowler
Copy link
Member

knowler commented Jul 17, 2018

@mtx-z

/**
* Here's what's happening with these hooks:
* 1. WordPress initially detects theme in themes/sage/resources
* 2. Upon activation, we tell WordPress that the theme is actually in themes/sage/resources/views
* 3. When we call get_template_directory() or get_template_directory_uri(), we point it back to themes/sage/resources
*
* We do this so that the Template Hierarchy will look in themes/sage/resources/views for core WordPress themes
* But functions.php, style.css, and index.php are all still located in themes/sage/resources
*
* This is not compatible with the WordPress Customizer theme preview prior to theme activation
*
* get_template_directory() -> /srv/www/example.com/current/web/app/themes/sage/resources
* get_stylesheet_directory() -> /srv/www/example.com/current/web/app/themes/sage/resources
* locate_template()
* ├── STYLESHEETPATH -> /srv/www/example.com/current/web/app/themes/sage/resources/views
* └── TEMPLATEPATH -> /srv/www/example.com/current/web/app/themes/sage/resources
*/
array_map(
'add_filter',
['theme_file_path', 'theme_file_uri', 'parent_theme_file_path', 'parent_theme_file_uri'],
array_fill(0, 4, 'dirname')
);

@mtx-z
Copy link

mtx-z commented Jul 17, 2018

Thanks.
Strange thing is :

dump(get_template_directory());
dump(STYLESHEETPATH);
dd(TEMPLATEPATH);

Right after it, or from the app controller always gives me (from a WP or Woocommerce endpoint), even after removing all updates made :

"C:\laragon\www\project/wp-content/themes/project/resources"
"C:\laragon\www\project/wp-content/themes/project/resources"
"C:\laragon\www\project/wp-content/themes/project/resources"

I'm gonna check on a clean install and see.

Thanks again.

@QWp6t
Copy link
Member

QWp6t commented Jul 17, 2018

@knowler actually those docs aren't correct anymore. we used to have a hack that would cause the STYLESHEETPATH to be changed to the path of the views, but it was a little too ham-fisted and caused errors for some users, including "broken theme" errors in certain situations. so ... i guess i should update the docs lol

@mtx-z the current setup is deliberate. it ensures parity between stylesheetpath and templatepath, making sage more compatible with child themes. we use template hierarchy filters to direct wordpress to the views.

you can filter woocommerce's locate_template function or just stick with resources/woocommerce and add that folder your view paths in config/view.php. or you're welcome to re-add the previous option hack if you want.

@QWp6t
Copy link
Member

QWp6t commented Jul 17, 2018

i'm going to go ahead and lock this, though, since this issue is 3 years old.

@roots roots locked and limited conversation to collaborators Jul 17, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants