-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Custom templates not loading since latest update #1870
Comments
confirmed bug, thanks for reporting |
it looks like wordpress hardcodes looking for page templates beyond 1 level deep 😱, see http://wordpress.stackexchange.com/a/250024 / https://github.com/WordPress/WordPress/blob/503d42fe6bcd2f45b3af78657686f8a27ccb0136/wp-includes/class-wp-theme.php#L1034-L1045 from what i can tell so far, we'd have to duplicate the ...then use the |
oh jeeze |
How about setting the templates in the cache to avoid the issue entirely? Since that method is checking with |
@derkjn how would the issue be avoided by doing that? that solution still requires duplicating a bunch of functionality in the WP theme class |
If we preset the list of templates in the cache before wordpress gets to that point, instead of searching for php files in the first level deep, it will return what's in the cache, which basically goes down to accessing the following:
|
right. where are you getting the list of custom page templates from without duplicating the functionality from the WP theme class? |
The only thing you need to duplicate is the regexp to parse the files, other than that why not just
|
i mean we're not really avoiding the issue at that point :) i was confused as you made it seem like there was an easier solution. we also need to re-create |
Sorry I was in a bit of a rush and didn't make myself really clear :) |
Alright so after playing with it for a bit I got to this working solution:
Any feedback is most welcome. If accepted I'm happy to open a PR with it :) |
The following line |
Thanks @ciromattia for pointing that out, code updated 😄 |
I get a lot of notices with that code. Could you change
and just rename $full_path to $file? |
@Kimers what kind of notices? |
Warning: file_get_contents(resources/views/.): failed to open stream: Permission denied in app\filters.php Warning: file_get_contents(resources/views/..): failed to open stream: Permission denied in app\filters.php Warning: file_get_contents(resources/views/layouts): failed to open stream: Permission denied in app\filters.php Warning: file_get_contents(resources/views/partials): failed to open stream: Permission denied in app\filters.php Other then this it seems to work just fine. |
Strange, are you sure your directories have 755 permissions? |
Have no idea, it is on a WAMP local server, not sure it is even possible to manage permissions that apache would recognize with that or how to set that up. It does not have an issue with the php files, just the folders and "." and ".." (not sure what those are). Seem to me the issue is that we can't just assume that we can use file_get_contents() on everything scandir() returns. The trick for me seems to be to filter out everything else then those php files. is_dir() seems to return true on the "." and ".." and the two folders. |
Including @Kimers changes will introduce a new problem for undefined $full_path variable on child templates Also the above method breaks child pages that use the js router
Although perhaps something that could be fixed here instead https://github.com/roots/sage/blob/master/app/filters.php#L8 |
This seems to be a temporary fix for the parent class but probably not the ideal approach:
|
Thanks for the feedback everyone! Updated the hook to exclude directories as well 😄 |
Any update with this bug? :/ |
@alexkerber there is a pull request waiting to get merged to master. If you need it now, just get the code from the pull request and implement it yourself real quick, that should solve the problem: https://github.com/roots/sage/pull/1876/files |
I can confirm it works smoothly with Bedrock and Valet 👌 |
* Resolves issue with WP only looking one-level deep for templates #1870 * get_template_dir() and related functions now point to sage/resources * Use collect() when assembling views paths
* Resolves issue with WP only looking one-level deep for templates #1870 * get_template_dir() and related functions now point to sage/resources * Use collect() when assembling views paths * Update tree in README
* Resolves issue with WP only looking one-level deep for templates #1870 * get_template_dir() and related functions now point to sage/resources * Use collect() when assembling views paths * Update tree in README
* Resolves issue with WP only looking one-level deep for templates #1870 * get_template_dir() and related functions now point to sage/resources * Use collect() when assembling views paths * Update tree in README
* Resolves issue with WP only looking one-level deep for templates #1870 * get_template_dir() and related functions now point to sage/resources * Use collect() when assembling views paths * Update tree in README
fixed by #1877 |
Submit a feature request or bug report
Bug report
It looks like after the latest update of sage, the custom templates aren't working anymore. I tested it on two different installations and for both the custom templates don't appear under page attributes. I guess it has something to do with the move of templates/ to resources/views/ and src/ to app/ but unfortunately I wasn't able to figure out where the problem is.
Specifically I'm talking about this template/templates
resources/views/template-custom.blade.php
The text was updated successfully, but these errors were encountered: