szabesz

@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!

To simplify it a biny bit: function addClass($element, $class) { $classes = wire('classes'); $classes[$element][] = $class; wire()->wire('classes', $classes); } Anyway, thanks a lot bernhard! When reading LostKobrakai's comment, I was also wondering how we can we use it any context, but I did not spend the time to figure it out on my own

When the administrator should be able to change settings, your solution works fine, however, adding our own standard classes to HTML elements is a different problem I think. bernhard wants to create a collection of HTML classes which can be easily applied to an element, and normally we do not want the administrator to change these values. Building these collections the beginning of the template file is good idea.

@bernhard: Seems to work. Can you please test it? function addClass($element, $class) { $classes = wire('wire')->classes; $classes[$element][] = $class; wire('wire')->wire('classes', $classes); }

I am still trying to figure out if there is a way to access the wire object directly "from anywhere", but we can pass its reference to the function to make it work: function addClass($element, $class, $api_vars) { $classes = $api_vars->wire('classes'); $classes[$element][] = $class; $api_vars->wire('classes', $classes); } so in a template: addClass('tm-main', 'tm-blog', $this->wire); Just a sidenote: I do not think $api_vars->wire('classes', $classes); is needed since $classes contains a reference to the object and by doing $classes[$element][] = $class; we actually change the object so no need to store $classes once more. Edit: I have just tested it, and we do need the above, sorry!

Hi boys, First of all, it is not early morning, so I got back to this one bernhard wrote: "using PW 3.0.12 it did not work with the example of tpr above using wire(x, y) without $this..." Actually, this has nothing to do with PW version, since $testArr is just a local variable, in the scope of the template and not related to the wire object. This way $testArr is not stored as an API variable. To append it to the wire object, we do need to access it via $this. See public function wire($name = '', $value = null, $lock = false) in /wire/core/Wire.php. The function wire($name = 'wire') in /wire/core/Functions.php can only retrieve variables but it cannot set them. So wire('testArr', array()); has no effect. The code only works, because we are dealing with variables in the same scope. Correct me if I'm mistaken, but I cannot come up with another explanation.

@Martijn Geerts: Yeah, although these naming conventions are logical, it is easy to get confused sometimes. @tpr: Actually, I was drinking my coffee why fiddling with the above code, but doing these two activities at the same time made things worse, I suppose