szabesz

It seems to be covered by the docs: https://processwire.com/api/selectors/#sort

Aha, sorry! So it was part of the same line of thinking and I should not have separated it. "Enabling" is probaly a better word in this context, but I'm just an English learner...

Additional panel? Well, we already have quite a few of them. Isn't it possible to manage all this in the current panel? Maybe I'm missing something, but it would also be a bit confusing to manage related panels. Currently all panels are completely unrelated, which is probably the expected behavior. Sounds OK! Once we can tell those states apart, we will also be able to visualize it

I'm not a hardcore dev either and my only encounter with Laravel was the one and only occasion when I fiddled with it for a few hours. Laravel seems to be a heavyweight campion with all those 20k+ files you need to implement even a Hello World app. Incorporating only about 1800 files, ProcessWire is definitely on the lightweight side. With its friendly community, constantly improving documentation and features I opted for ProcessWire instead of all the others I also checked out. ProcessWire sites are also easy to manage, upgrades are rarely an issue if performed with some very basic care, (say, if you modified your .htaccess, then do not replace it with the default one while upgrading, etc...). Even if you run into issues, our above mentioned friendly community is ready to help right here in the Forum

I always think of ProcessWire as complete PHP framework bundled with integrated browser based content management tools (hundreds of tools, actually). ProcessWire should be listed here: https://en.wikipedia.org/wiki/Comparison_of_web_frameworks#PHP You do not even have to use the CMS if you don't want to, but why reinvent the wheel?

If we keep the Validator panel off and enable it temporarily with the Once option, we get a similar - though not exactly the same - effect, if I'm not mistaken. When we decide to use it more than once, now we can just choose Sticky. When you switch to Sticky, you do not have to click anywhere anymore just to validate the page once more. To me it looks like a good workflow. An on-demand validation would stay on-demand, but what if we are in a long session of fixing some validation issues? In that case we would need another option to switch between on-demand and automatic in order to save some time and clicks. Another issue: The Once and Sticky button features might need some additional polish: currently there is no way to tell apart Sticky and the standard default state, after a while we cannot remember the reason why those checkboxes are on or off. Some sort of color coding might be good to implement to solve this. Say, green is used to indicate the temporary Sticky state. Or maybe an icon (::after selector probably?) An icon is more descriptive, so probably a better solution.

Thank you very much! Now the "Panel Selector" panel looks like just the one on your screenshot and works fine. Implementing it was really cool idea, I also used to switch panels on and off a lot of by going to the PW settings, so it is a real timesaver.

Sorry for not being clear! Version 1.4.9 did not solve the problem of the labels sliding under the checkboxes, so if it is ok, please to add those styles to Tracy. Since you mentioned it, I also tried to fix the issue with "all: initial", but could not figure out anything that cloud work.

Thanks Adrian! Probably this change made the checkboxes clickable. As for the css issue, I could fix the issue of the boxes covering the labels by applying these rules: #tracy-debug input[type="checkbox"], #tracy-debug input[type="radio"] { width: 12px; height: 12px; position: static; } Sure, the radio version is not needed in this particular case, but my css "framework" also define its rules for that selector, so just in case... Position was absolute, so that is why the labels slid underneath the checkboxes, and dimensions were also quite "incompatible", so to speak. I will look into my performance issues as well (when I have the time) and report back. I've also noticed the new version being released in the meantime. Keep up the good work, your fans – including me – love this gem!

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