szabesz

Actually, this is the blog post in question: the one about ProcessWire 3.0.14 I have just tested and you are right, it does not seem to work (PW 3.0.15). I set all the "Use Compiled File?" settings to auto, cleared the template compile cache folder (/site/assets/cache/FileCompiler/site/templates) and the files keep coming back. And my template files start with namespace ProcessWire;

Hi Soma, Moved the folder "ClearCacheAdmin" into the modules dir. Clicked Modules > Refresh, got this: Compile Error: Arrays are not allowed in class constants FIle: .../modules/ClearCacheAdmin/ClearCacheAdmin.module.php:11 class ClearCacheAdmin extends \ProcessWire\Process{ const exludeCacheDirFiles = array("Page", "MarkupHTMLPurifier", "MarkupCache"); Solution? Thanks in advance.

This is more that I could dream of Thank you very much!

As fas as I know, currently there is no way for a module developer to include a changelog in a way that enables us to check out the changes in the admin before upgrading.

Thanks a lot! Just one question: how about cache/FileCompiler too? Or better yet, any number of custom paths added by the superuser? Maybe I'm asking too much.

"...added layer of complexity (and another syntax to learn)" Sure, one has to learn a template engine in order to utilize its full potential, but your own design pattern can quickly grow too, becoming more and more complex as time passes by. So, implementing your own design pattern takes time, learning someone else's also takes time. It was not adrian's nor tpr's intention to convert me, but just because of seeing what Tracy is capable of and reading about Nette Forms and Latte, I started to learn something new and dropped the idea of creating something basic that can fit my needs in the short run, but will be an obstacle in the future. Also, this way I opted for something that guides me in implementing secure frontend, which is an added bonus.

@pwired: How about using wireRenderFile() so just you specify which template partial you need, effectively using them (and their Page counterpart if needed) as "blocks". If it is just something that displays data coming from other Pages (say last five blog posts), we do not even need its own page, it is just a lonely "block/widget", but we might need to configure it somehow, so some sort of storage might still be needed. Since there are no rules for the frontend, it depends on our creativity to setup our own "blocks system".

How about utilizing the console? Similar to fireLog() https://processwire.com/blog/posts/introducing-tracy-debugger/#firelog

Should be part of core. Disabled by default, enabled optionally Same goes for InputfieldSelects After all, how can we make them really required if one is always selected, even by default?

Although in the case of real projects I find it nearly impossible to produce HTML output that is considered to be valid by the W3 validator, I think it is a good idea to have a quick look so that anything considered to be a bug (say not closed elements) can be quickly identified. So I support the idea.

Thanks again, Ryan! For the update and for educating us (best practices with fields...).

Maybe you are looking for WireHttp::download() ? https://processwire.com/blog/posts/august-2014-core-updates-3/#new-download-capabilities-in-wirehttp-class "...First it attempts to use cURL..." Never used it though, just guessing. Sorry if ti is not the one you need.

Hi, How about Tracy Debugger's "Debug Mode" panel? There aren't too many queries listed for an almost empty frontend page.

With Adrian's TracyDebugger module, we get a list of loaded modules in the Debug Mode panel. Maybe this is the tool you are looking for?

@Jonathan: You have covered "Data Migration", but does it include "site migration" too? Sure, normally it is a straightforward process, however you might want to demonstrate it as well, just to contrast it to the complete WordPress migration process. For example I have my own Bash script (utilizing wp-cli among other built in Linux tools) for migrating WordPress sites and probably it is also possible to implement something similar with Wireshell. I'm not saying that you should spend too much time on the issue of site migration and Wireshell, and you might have already cover the issue of complete site migration in one of the episodes, still if not, you might want to dedicate a few minutes to it. Otherwise you presented such a thorough list of everyday issues that it is hard to recommend something else to add to it. I can't wait either! Thanks in advance!

@kixe: Thanks! This can be quite useful sometimes. I have never noticed this list before.

Thanks for educating me, teppo! I have never used GitHub (apart from downloading ZIP files and simple browsing) nor noticed the "forked from" line. Sooner or later I need to find the time to familiarize myself with GitHub, I suppose. And again, sorry for the off-topic question.

Is it possible that you are using it on a live site or at least a publicly accessible server and not your local machine?

Thank you for the answer! Is it also standard not to reflect this in README.md and just copy it over? I mean, how can one tell apart the various forked versions? Just by looking at the "main pages" of the projects, they seem identical to me. Sorry if it happens to be an off-topic GitHub question.

May I ask why it is a good idea to fork it, instead of including these features in the original module? Am I missing something perhaps? I'm not a GitHub guru, so I ask: doesn't it mean that these are two completely separate projects from now on?

@Soma: Thank you for the detailed tip! I think it is more versatile than what we have came up with so far. As far as I can tell, your render method example covers the particular use case we dealt with in this thread and surely with even more helper methods added to the class all sorts of utilities can be implemented.

Hi, If I understand the issue correctly, you might want to check out these modules, so that you can show the default: http://modules.processwire.com/modules/template-notes/ http://modules.processwire.com/modules/fieldtype-runtime-markup/ http://modules.processwire.com/modules/inputfield-textarea-markup/

I do not know too much about opcache, however I think is important to point out that whenever I use it I notice that when updating files the cache is not immediately refreshed but it takes several seconds (somewhere between 0-30) to be able to see the changes being applied. So in my experience opcache makes testing code changes painful during development.

So this is a nice example of the confusing nature of any "long-do-this-or-that" interface constructs. I never liked them. They are used all over the place (tv front panel controls, watches, touch screen devices) but it does not mean it is an intuitive control method. Luckily the virtual screen of a computer is not limited to a few number of buttons, so I do not understand why this confusing way of controlling things should be used at all.

I should have thought that you are also working while traveling Thanks again for one of the most useful modules and for the blog post as well!