tpr

Middle-click to open link: sorry, it was the same page that opened, not the one in the list. What if it had a link too, would the modal stop functioning? Empty "name" for non-default language names: perhaps using square brackets, or something similar, eg "*pagename"?

Thanks - all seem to work fine here. I feel the empty "name" column for non-default language is a bit misleading, perhaps adding the default name there in grey would be less confusing? Now it looks like there's no name provided (which can't be as it's required). Plus this way you don't know the page name. The new edit mode for me is not very helpful because I can open the modal link in a new tab with middle-click. But of course it can be handy for others. Btw, what about displaying the "Active" state of pages in multilanguage installs?

Haha, that was my first idea when reading the intro of your post I would say yes, and that would allow seeing the default title when clearing the field (if you add the placeholder to all title fields, not only to empty's)

I guess blanks would be better if that would prevent unintended saves, thanks. Hiding them in a tooltip is perhaps not the best idea, it would be better to make them visible all the time (wouldn't require hovering with the mouse). Actually I could add non-default language titles and other titles were remained intact. But I have the Page Rename Options plugin installed, maybe that's interfering.

@adrian On a multilanguage site, loading the Children tab (BCE) shows the titles for the default language if there are no title set for the current language which is fine. But if I save the page, even without any editing, these default titles are saved to the DB (for the non-default language). This happens only after navigating to the Children tab. From a user/editor POV I regard this as a bug, do you think there's an easy fix? So do not overwrite empty titles with the titles from the default language. Currently it's not an issue because all titles will be translated for all languages but it's a bit confusing imo.

Another filter added in v036: embediframe. Unlike other responsive embed setups this one uses two wrappers to allow setting custom width so the iframe won't necessarily fill the available horizontal space. There's also a protectemail filter available and the bodyclass filter was updated to include paginated pages too.

Shit happens. Everywhere.

It's definitely easier https://processwire.com/blog/posts/pw-3.0.44-repeaters/

Perhaps this could work in twig templates too - in ready.php add this: $view->bd = function($data) { bd($data); }; then use this in twig files: {{ $bd('hello world') }}

I do not use this module but these mods are looking great. How about adding the labels to the left of the fields? that would make the form look less crowded and easier to overview. I'm not sure whether the markup allows easy style update.

Maybe $e->replace = true? But I would use Tracy Debugger to find out what's going on.

Another alternative could be having a "<parent />" element inside the "header", just like in template engines. This would be replaced with the header contents you have set earlier. You could use this element as the first or last one inside the header, or anywhere else. Because of such issues wrote I earlier that I find this approach similar to blocks in template engines. But if it's so, PW should borrow existing solutions from those.

Perhaps using indentation for nested fields could be more clear and space efficient instead including fields inside fields, what do you think? Or is such level of modification out of scope for now?

Experiment with pagelist counters (CSS only):

Do you get these values on the same server (same PHP version)?

v033 is available that contains two new filters, lazy and surround. I like the succinctness of the surround filter, eg in case of a tag list: {$p->tags->sort('name')->title()|surround:'li'|surround:'ul class="tags"'|noescape} <ul class="tags"> <li>one</li> <li>two</li> <li>three</li> </ul> The docs were moved to GitHub Wiki, the increasing number of filters required this.

I think it's similar to twig's parent(): http://twig.sensiolabs.org/doc/2.x/functions/parent.html

Thanks! That was a silly mistake, interestingly noone spotted it, including me v125 is uploaded with the fix.

I think I got it - I've refactored the submodule enabled state to a function but haven't updated it everywhere, will commit a new version soon. Update - @Macrura could you test if this solves the issue? AdminOnSteroids.min.js

Could you check the Body field settings? Re-saving the field may fix this. My idea is to make a hard reload, config.js often gets cached. What have you upgraded and to what version?

Thanks, good suggestion, I haven't thought about this. Although for newbies it can be harder to understand. It works in Latte too but I'll keep the 'default' filter as it's easier to use, especially when chaining filters: {($page->title|replace:'Home','') ?: 'No content available.'} {$page->title|replace:'Home',''|default:'No content available.'}

Just added a new filter 'default' (v031) - this seems to be a nice shortcut for simple if-else conditions. <div> {$page->product_description|default:'No description is available for this product.'} </div> I guess the core PW API could also use something like this: $page->get('product_description', 'No description is available for this product.') What do you think?

I like this approach because of less number of template files. Sometimes I end up with 10+ templates and it gets duplicated because of the view files. Keep in mind that you should use ready.php (or another one) to act as a controller if you still need to separate concerns. There you can use conditionals to target the current template or even include another php files if needed - I often include files eg. in case of the search template to keep ready.php less crowded.

Thanks! The old method is better to forget, the module is the way to go. The latest filters and latte-only template files make templating even more enjoyable. Recently I updated an earlier site of mine and I could throw off about half of the template files and the code is also much cleaner/maintainable.

Sure, that will come handy, thanks!