szabesz

Thanks for everyone being involved! I have one issue though, see image: This is a transparent png, a completely white logo that used to be visible, thanks to ProcessWire properly dealing with the issue (before the upgrade). Now we cannot see it anymore, also the new layout and the new buttons are useless in this usecase. The logo is horizontal (a lot wider than its height) and now I might want to set its Column Width a lot wider so that the image is not rendered in such a tiny size. However, I cannot see the image anyway, so for the time being this width might do... BTW: I will never want to crop the image (being a site logo, it is already resized to my liking), it will always have only one variation, so these buttons can clearly be useless, just take up precious space. Also, what if I do not want clients to fiddle with crop? It would be nice to have options to turn these button on/off. Say, on the Input tab where Column Width can be set among other options. I'm also missing a list view. Actually, for basic needs, the old way of doing things worked better. Now we have a lot of bells and whistles, but some basics needs are not fulfilled anymore. I hope this will improve in the future. Thanks anyway! EDIT: please read teppo's comment below, too. He did a great job of further clarifying what I meant.

Cheatsheet tip: sometimes its search feature can help too, when we can gess the right keyword, such as: http://cheatsheet.processwire.com/search/?q=include The answer is still one (or a a few) click(s) away though, but it is often worth a try.

Thanx for sharing your findings!

I think Robin S is right. It would be nice if this behavior was pointed out in the docs.

@louisstephens: so you followed these instructions: http://processwire-recipes.com/recipes/create-custom-admin-settings-page-link-in-admin-menu/ right? In _init.php (delayed output method) I just do this: $settings = $pages->get("/settings/"); and later on, access settings like this: <h1><?= $settings->site_title ?></h1> Sure, we can use the ID of the page too, but it is easier to remember a string, which can be the same in different projects, while IDs might differ.

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.