szabesz

Thanks Adrian! I could speed thing up considerably (especially by switching to stable from master, but turning off two additional panel helped too.) However, I cannot use the checkboxes in the Panel Selector panel. Probably my css rules conflict with the ones needed for this panel to work. The checkboxes are situated over their "labels" respectively and the click event is not handled at all, not matter where I click, nothing happens. I did not spend too much time to investigate what causes this, so I don't know it yet, but by turning off all linked styles (by using Chrome's Web Developer extension by Chris Pederick) the layout of the panel is back to normal and the checkboxes work as expected. Isn't there a way to make sure that this panel works whatever css rules the underlaying page has?

Hi Soma, I've just installed ModulesManager which generally seems to work fine on 3.0.16, however it does not find Tracy Debugger. Is it something to do with the fact that it's running on ProcessWire 3.0.16? Probably not, however it is rather strange that this module in question is not listed.

The old list view is not that useful anymore, but seeing the list view of the Variations, now that is what (or something similar to it) would be useful. That way we could see the complete filename, for example. Some Ajax driven editing features would be quit useful too. This is not a media query issue, the "box" is narrow on a wide viewport, because I adjusted its Column Width setting (30%). Do not get me wrong, I realize that these new features are big improvements, it just feels a bit 1.0

Here is the related old blogpost: https://processwire.com/blog/posts/quality-assurance-for-images-in-rich-text-fields/

Thanks teppo! You saved me a lot of typing by clarifying what I meant

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;