XF 2.0 Issue with editing templates on the filesystem

Myke623

Well-known member
I'm following the "Let's build an add-on" in the dev docs and ran into an issue with creating/editing templates directly on the filesystem. Put simply, any changes I make don't appear to be seen. If I instead create/edit the template via the ACP, then the file is immediately written out to disk. Is there something (a configuration option, a setting?) I'm missing that is preventing this from working?

I'm using v2.0.0 Beta 3, on Windows 10, and EasyPHP as my "WAMP".
 
Last edited:
Just to confirm, are you referring to development mode things? And when you do things in the control panel, the changes are written to the development mode files?

I can't really see why this wouldn't work and we haven't had any other reports of it. (You're not running the latest beta, though I don't think that's related.)
 
Just to confirm, are you referring to development mode things?
Correct, both debug and development modes are enabled via my config.php. The particular step within the "Let's build an add-on" doc was Creating the portal page with the instruction to manually create the demo_portal_view.html template within the specified path of src/addons/Demo/Portal/_output/templates/public/. Doing so did not resolve the missing template error.

And when you do things in the control panel, the changes are written to the development mode files?
Correct. Creating/editing the template via the ACP results in the changes written out to the file within the _output path.
 
If you create the template in the control panel and then edit it in the file system, do the changes get picked up when you next refresh the page (using the template)?

Actually, just to clarify, what action are you taking where you expect the template to be created in XF via the file system? This only happens when the template is actually requested.
 
If you create the template in the control panel and then edit it in the file system, do the changes get picked up when you next refresh the page (using the template)?
No, they do not get picked up.

Actually, just to clarify, what action are you taking where you expect the template to be created in XF via the file system? This only happens when the template is actually requested.
The action I took, after manually creating the .html template, was to simply "visit the portal page", as instructed by the dev doc under Create a portal page:

As was mentioned in the View reply section, the first argument is a view class, but we don't need to actually create this class. This class could be extended by other add-ons, if necessary, even if it doesn't exist. The second argument is the template, which we need to create now in the path src/addons/Demo/Portal/_output/templates/public/demo_portal_view.html. That template, for now, should simply contain the following:

<xf:title>Portal</xf:title>

If we now visit the portal page, the template error will be gone, and although we will still have a fairly blank looking page, it will at least now have the title "Portal".
 
Update: I ran through the "Let's build an add-on" guide again in a different environment (Beta 6, Windows 7, Bitnami WAMP) and template editing in the filesystem worked as expected. I might try another re-do in Windows 10 environment where I previously experienced the issue and report back.

However, with this second run through, I experienced a couple of issues (bugs?) with the pagination implementation that I also encountered the first time around:
  1. When the page limit was hard coded ($perPage = 5), manually changing it and refreshing the browser didn't always result in the Portal page reflecting this change. Multiple reloads/refreshes were often required. I suspect there's some caching in effect that I can't seem to flush with the reload?
  2. With the Portal add-on development completed, I've found myself in a situation where page two on the Portal shows "No threads have been featured yet" even though some threads should be there. For example, I have five threads featured, as confirmed in the table xf_demo_portal_featured_thread, and when the "per page" option is set to a number greater than or equal to 5, then all five threads are correctly featured. However, when this number is less than five, the correct number of threads are shown initially, but when you navigate to the next page (page 2), no threads are shown. Is this a bug, an issue with my development environment, or have I done something wrong in the development?
Finally, in going through the guide I took down a bunch of notes in the form of suggested improvements, inconsistencies, typos, etc. Would you guys be interested in me posting this, and if so, where's the best place for it?
 
When the page limit was hard coded ($perPage = 5), manually changing it and refreshing the browser didn't always result in the Portal page reflecting this change. Multiple reloads/refreshes were often required. I suspect there's some caching in effect that I can't seem to flush with the reload?
That will likely be PHPs built in opcache.

You can change it in php.ini or you can add the following to config.php:
PHP:
ini_set('opcache.revalidate_freq', 0);
 
That will likely be PHPs built in opcache.

You can change it in php.ini or you can add the following to config.php:
PHP:
ini_set('opcache.revalidate_freq', 0);
Neither changing the global (php.ini) or local (config.php) setting to opcache.revalidate_freq=0 had any effect. Page two still shows up as blank where there should be featured threads. Any other suggestions?
 
I might try another re-do in Windows 10 environment where I previously experienced the issue and report back.
Just to close the loop on this one, I finally got around to re-doing the guide in the aforementioned Windows 10 environment but with Beta 6 instead of Beta 3 and Bitnami WAMP instead of EasyPHP, and template editing on the filesystem worked as advertised.

I'm still not sure what happened previously, but I'm happy to leave it behind and move on.
 
Top Bottom