szabesz

Probably $config->adminEmail = "info@example.org"; Anyway, thanx for the explanation, Kixe! I did not know this either.

Another option is to implement something basic. If you do not have too many levels, you can do it without going recursive: <ul class="menu-ul"> <? foreach ($children as $level1): ?> <li<? if ($level1->id == $page->id) echo ' class="active-item"' ?>> <a href="<? echo $level1->url ?>"><? echo $level1->title; ?></a> <? if ($level1->url != $homepage->url): ?> <? $children = $level1->children(); ?> <? if ($children->count() > 0): ?> <ul> <? foreach ($children as $level2): ?> <li<? if ($level2->id == $page->id) echo ' class="active-item"' ?>> <a href="<? echo $level2->url ?>"><? echo $level2->title; ?></a> <? $children = $level2->children(); ?> <? if ($children->count() > 0): ?> <ul> <? foreach ($children as $level3): ?> <li<? if ($level3->id == $page->id) echo ' class="active-item"' ?>> <a href="<? echo $level3->url ?>"><? echo $level3->title; ?></a> </li> <? endforeach; ?> </ul> <? endif ?> </li> <? endforeach; ?> </ul> <? endif ?> <? endif ?> </li> <? endforeach; ?> </ul>

Considering the new "File Compiler modules" feature of PW, it actually depends on your requirements: https://processwire.com/blog/posts/processwire-3.0-alpha-2-and-2.6.22-rc1/#file-compiler-modules However, most of us will rarely use this tool, I suppose...

So changing the salt is good for locking out everyone... Or at least to force them to reset their passwords if they are allowed to do so in the first place.

From time to time people run into this issue: https://processwire.com/talk/topic/13089-repeater-field-limits-and-server-timeouts/ So the idea is simple: Admin > Setup > Fields > Details (tab) > Maximum items allowed / 0 = No limit Something like the one for images. And may be a nice little yellow boxed notice underneath, about why it is a good idea to impose a limit... I love these inline help bits, they help me a lot. EDIT: I forgot to add that - of course - we also need some GUI voodoo to support it.

Thanks cstevensjr! I have confused "ProFields: Page Table" with Ryan's "ProFields" package for a moment or two or three or even four

Did I miss something? Where is it?

Even easier, if you install the Upgrades + Upgrades Checker modules in order to perform the upgrade with a few clicks (while reading the inline instructions carefully...)

Except when you introduce yourself to potential client and you must quickly transform into a professional (But that's off topic again, sorry for that...)

Thank you for clarifying this!

Introducing a (usable) standard is always a good idea. You might use ProcessWireUser, but what if my convention was WireUser_Process? How can my fellow programmers figure out my intention easily, just by taking a quick look at my code? The other advantage is "reminding" the developer to actually use "prefixing" which we tend to forget otherwise. EDIT: not to mention the possibility of organized libraries with autoloading...

That's black magic It must have been some sort of cache issue, I suppose. Works fine after updating, thanks once more!

@Soma: did you really commit that change? Seems the same gives the same error. Am I missing something?

We currently have the option to designate a field to be "Global". It might be possible to introduce the "not so global" option, meaning the filed to be configurable in the Template settings to be "disabled/not used". This might get a bit convoluted, but if we could somehow get an overview of what is actually used and where, it might work.

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...).