PW 3.0.194 – Core updates

[ryan]

This week I've bumped the dev branch version to 3.0.194. Relative to last week, there are a few commits fixing minor issues. Last week we covered some fairly major updates and I've not come across any concerning side effects, so figured it's a good day to bump the version. Next week my kids are out of school for winter break so I'll be around but I don't expect I'll have much in terms of updates to report next week, but definitely will the following week. Thanks and have a great weekend!

[7Studio]

Hello @ryan, first of all huge thanks for a great addition to the core, but I'm a bit concerned if lazyLoading should be enabled in the core by default as it is since 3.0.194.

To give an example where I'm having problems - I have a small function that renders site main menu, where I do check if page templates allows to have a children pages (template noChildren value), if not - they are not rendered in main menu (this is my basic setup for pages like blog posts, portfolio items etc. - these are treated as final pages with no children allowed).

The part of the code that renders site menu looks like:

			if ($item->hasChildren()) {
				$id = $item->template->childTemplates;
				$fields = wire('templates')->get($id);
				foreach($fields as $field) {
					if (!empty($field->noChildren)) {
						$no_children = true;
					}
				}
			}

Unfortunately since this update, I can't access page templates settings fields values as long as I'm not on that exact page, so in this example all my blog posts are rendered in menu while I'm not on a blog post page.

Disabling LazyLoading:

$config->useLazyLoading = false;

in my config fixes this and brings previous behaviour. Not sure if this is a bug or it was intended, or something is wrong with my code ? but for me one of the most powerfull option of PW is a fact, that I can access anything -page/field/template from anywhere. If that was intended I guess that that other people could have similar problems. While this is a great improvement in overall loading speed, I think that this option should be disabled by default (if it may cause that kind of side effects), and to be left to the final user to decide, if it is needed and should be enabled - same as we don't use cache by default.

I would love to hear yours and others opinion in this matter. Thanks!

[AndZyk]

4 hours ago, 7Studio said:

To give an example where I'm having problems - I have a small function that renders site main menu, where I do check if page templates allows to have a children pages (template noChildren value), if not - they are not rendered in main menu (this is my basic setup for pages like blog posts, portfolio items etc. - these are treated as final pages with no children allowed).

Maybe I am missing something, but wouldn't it be enough just to check for $page->hasChildren()? What is the benefit of the extra check of the template settings?

I always just use $page->hasChildren() for building navigations, because if I have set in the template that a page cannot have children, it will not have children. ?

Spoiler

<?php if (count($nav)): ?>
    <nav>
        <ul>
            <?php foreach ($nav as $child): ?>
                <li>
                    <a href="<?=$child->url?>"><?=$child->title?></a>
                    <?php if ($child->hasChildren()): ?>
                        <ul>
                            <?php foreach ($child as $grandChild): ?>
                                <li>
                                    <a href="<?=$grandChild->url?>"><?=$grandChild->title?></a>
                                </li>
                            <?php endforeach; ?>
                        </ul>
                    <?php endif; ?>
                </li>
            <?php endforeach; ?>
        </ul>
    </nav>
<?php endif; ?>

 

[7Studio]

Hi @AndZyk, Thanks for your reply!

Maybe I wasn't clear enough, to explain this further - I would like to avoid including childrens as menu items even if they exist in some scenarios, for example hierarchy of my blog looks like this:

• blog page (blog template)
  • article (blog-post template)
  • article (blog-post template)
  • ...

In my case blog-post is a template that can't have children, but Your example will display every single blog article title as a child in menu, which of course I want to avoid.

By checking a blog-post template settings (noChildren allowed value), I can skip articles from beeing rendered in a menu and for example adding "parent" CSS class to blog page menu item.

I can do the same for other pages that follow same site structure, like portfolio -> portfolio item etc. while using template settings only.

For menus I prefer to have a single function that is used to render all kind of menus, that simple helps me to limit code and usage of if/else checks for a specific templates while building menu.

Anyway, since 3.0.194 I can't access these values any longer, (as long as I'm not on a blog post page).

Lazy loading in this case limits my access to needed values, so I'm wondering what else can't be accessed and if that is not much to have it enabled by default, when PW in most cases is blazing fast (Just loud thinking)  ?

 

[szabesz]

7 hours ago, 7Studio said:

I'm a bit concerned if lazyLoading should be enabled in the core by default as it is since 3.0.194.

Me to. Just recently I've read two PRO module forum posts where the PRO modules did not work properly with lazyLoading enabled. I am surprised that Ryan enabled it by default, as usually he does the opposite, like in the case of Markup Regions, Page Classes and Functions API. Why should useLazyLoading be en exception to this?

Now I need to add $config->useLazyLoading = false; to all the configs of all "my" sites to be on the safe side.

[bernhard]

@7Studio I don't understand. Which property can you not access? Can you give a generic example?

[AndZyk]

16 hours ago, 7Studio said:

In my case blog-post is a template that can't have children, but Your example will display every single blog article title as a child in menu, which of course I want to avoid.

Thank you for your explanation.

In this case I would just use an additional if-condition.

if ($child->hasChildren() && $child->template->name !== "blog-post") {
	// Subnav
}

Maybe not elegant but simple. ?

[7Studio]

@AndZyk Thanks! ? but as I've mentioned above I would like to avoid those if/else and updating code everytime when I add/change something ?

After some more testing it looks that the problem lies in my code.
I'm using wrong method, childTemplates gives me ID of child template, while I should use childTemplates() - that returns array of templates objects, and it works with LazyLoading enabled.

Working example:

			if ($item->hasChildren()) {
				$template = $item->template->childTemplates();
				foreach($template as $child) {
					if (!empty($child->noChildren)) {
						$no_children = true;
					}
				}
			}

 

17 hours ago, bernhard said:

 I don't understand. Which property can you not access? Can you give a generic example?

@bernhard basically I couldn't access template object and it values, but this looks more like an edge case, and I couldn't find more generic example. You would need to have a similar setup (let say blog as parent template + child blog-post template that doesn't allow childrens) + code needs to lands in the _init.php and you have to be logged in.

$parent   = wire('pages')->get('template=blog');
$child    = $parent->template->childTemplates;
$template = wire('templates')->get($child);

var_dump($template);

With lazyLoading enabled this returns NULL instead of a template object (it ruturns object if you are on a child page).

As I've mentioned it looks that I was using wrong method, but I think that question still remains if lazyLoading should be enabled by defalut, especially if it can bring some code breaking changes - also like @szabesz mentioned above.

[bernhard]

53 minutes ago, 7Studio said:

As I've mentioned it looks that I was using wrong method, but I think that question still remains if lazyLoading should be enabled by defalut, especially if it can bring some code breaking changes - also like @szabesz mentioned above.

That's why I was asking for a generic example. I'd not be happy if lazyLoading was disabled by default. It's imho much better to add one single setting to old installations when needed (and I have not had any issues until now) than to have ProcessWire not use it's full performance by default. And don't forget updating old setups is a one time thing. I don't know how this feature works internally but I'm sure Ryan has made that decision thoughtfully.

[7Studio]

23 minutes ago, bernhard said:

That's why I was asking for a generic example. I'd not be happy if lazyLoading was disabled by default. It's imho much better to add one single setting to old installations when needed (and I have not had any issues until now) than to have ProcessWire not use it's full performance by default. I don't know how this feature works internally but I'm sure Ryan has made that decision thoughtfully.

Good point.