Leaderboard

I get paid by the hours so... oh wait. ? Good to hear it worked for you! ?

@bernhard Do you sleep sometimes?

Is your include file namespaced? If not, throw new \ProcessWire\PageNotFoundException(); should do the trick. Or adding "namespace ProcessWire;" at the top, obviously.

How about this: <?php $p = $pages->findOne(1241); if ($p->id) : ?> <a href="<?php echo $p->url() ?>"><?php echo $p->title() ?></a> <?php endif; ?> Perhaps it's only a minor optimization, but it saves it returning any page object if the page isn't published. Be sure to read the docs on findOne() vs get() to understand fully, but basically find() and findOne() won't return unpublished pages unless to specifically request them to, but get() will ignore unpublished and hidden statuses and always return a page if everything else matches.

Now you can join any finder to any column of another finder. That's quite powerful but might also get complicated or slow... It's especially handy when you want to use RockFinder2 as datasource of a RockGrid, because RockGrid does not support the new concept of relations that where introduced to RockTabulator https://github.com/BernhardBaumrock/RockFinder2/commit/8c6b66ad3dda68de9c1008078420f13a034250bf

@bernhard's post gives you the clue - it's to do with PW's built-in caching. $page->children() is a method that queries the database. You want to minimise the number of requests to the database because going to the DB is a lot slower than working with objects in memory. In your code you call $page->children() five times, so the expectation is that this would mean five trips to the DB... except that PW tries to help you out and caches the results to avoid unnecessary DB queries. But the exact workings of this caching are undocumented (as far as I know) and so I'd say it's best practice not to rely on it. It would be better to consciously minimise the DB requests in your code - it would make things clearer (i.e. avoid the confusion you're getting from the behind-the-scenes caching) and it's a good habit to get into for when you're working with other PHP projects that might not cache DB query results like PW does. You could rewrite your code like this: $layout->setTemplate('sidebar'); $selector = [ 'template' => 'product', 'sort' => 'title', 'categories' => page('id'), 'limit' => 9 ]; // Just get the children from the DB once // I assume you need all the children at some point later in the code because you dump page()->children() in your example. // If you don't need all the children then just get the categories directly with page()->children('template=category') $children = page()->children(); // Get the categories from the children PageArray (happens in memory) $categories = $children->find('template=category'); // If there are any categories then modify $selector if($categories->count) { $categories->add(page()); $selector['categories'] = $categories; } bd($children); bd($categories); And this might be getting into the zone of micro-optimisation but you could consider if you actually need full Page objects in a PageArray or if you only need the IDs (reduces the memory footprint): $category_ids = page()->children('template=category', ['findIDs' => 1]);; if(count($category_ids)) { $category_ids[] = page()->id; $selector['categories'] = $category_ids; }

Currently I stick to 3.0.138, looks like that is the last DEV version safe to update to.

Thank you, Adrian, now everything works as expected, also in fields of type TextAreas!

d($page->children()->count); // 7 $foo = $pages->get(1); $page->children()->add($foo); d($page->children()->count); // 8 d($page->children('id>2000')->count); // 3 $page->children('id>2000')->add($foo); d($page->children('id>2000')->count); // 4 $pages->uncacheAll(); d($page->children('id>2000')->count); // 3

Ok - good call on the namespacing. Can confirm the following combo of using wire404Exception() instead of PageNotFoundException() and namespacing works as follow: throw new \ProcessWire\wire404Exception(); Thanks @wbmnfktr and @BitPoet - got there in there end!

The same error is being discussed in this thread where throwing a 404 exception in an include file throws an exception (well, a different one). In that thread it seems that there are different scenarios that can trigger this. What I'd suggest right now is to install the Tracy module if you haven't yet to give you a better look at what's happening.

The 3.0.140 brought some issues with 3rd party modules and I try to avoid the DEV version at the moment for that reason. Therefore this was just a guess but maybe the DEV version also affects core features like this. Try the latest Master (3.0.123) if possible. If that's the fix we have found the suspect. By now your code snippet seems fine to me - at least the modified (other if statements and Wire404Exception) version works as expected here.

So... I just played with it a bit. Does NOT work: throw new PageNotFoundException(); Does Work: throw new Wire404Exception(); Tested it on a ProcessWire 3.0.133 installation. Are you maybe running the DEV 3.0.140 version?

Sorry for keeping you in suspense... but crazily I can confirm this works! Thanks for your help ?

Hi @xportde - sorry about that. I have reverted those changes and taken a different approach to what I was trying to fix. FieldsetPage fields now work as expected, but there is still a problem with the individual fields under a textareas field, but I don't think that is related to the version of this module - I just don't think the Textareas module supports setting "entityEncodeText" to false, which is how this module allows html in the description. If I am correct in this assumption, then it is something Ryan will need to fix. Let me know your thoughts.

$page->closest() might be the slightly better option (or might not): https://processwire.com/api/ref/page/closest/

Couldn't you use this, assuming all offices, eg HUMAN RESOURCES have a template names "office" $page->parents('template=office'); Actually you might want "parent" instead of "parents" to make it easier in this case.

In the last few weeks... or almost months... I worked on a project for a restaurant. Sad to say that the company behind the restaurant went out of business before the project could be finished - or was paid or the website ever saw the light of day. As there is kind of a lot of work in it... but yet a lot of customization... I decided to create a site profile of it and make it public as ProcessWire Barebone Site Profile. Right now I'm stripping out every client detail and finish some functions and details that were planned a few weeks back so you can build right on top of it, if you like or want. Maybe it's only a playground for someone or an inspiration for how to f**k up data-mangement... but hey... better than a ZIP file on a backup drive. ? As the project was and is super tailor-made to that client, it may not work for a lot of restaurants out there, but nonetheless I don't want miss the opportunity to offer a foundation for upcoming restaurant projects you may face. The project had a huge focus on dishes, beer and wine variations so those templates are kind of feature-rich. You might want to rip out some of it as most restaurants don't focus that much on those details. Important details I want to be honest and clear about: this profile does NOT include a highly polished and usable frontend as the design is paid and therefore can't be made public the frontend will be a collection of re-usable snippets to show every possible detail of each page, item and whatever the whole site profile will be without any support - future updates aren't planned right now the site profile will be released in single-language setup only (english) existing translations (as seen in parts of the screenshots) will be changed to english existing data, for example dishes, will be replaced with demo content if you, one of your clients or anyone else wants to use this profile - feel free to do so Pro Modules were already stripped out of it only public modules were used and are included with the profile itself the full module list will soon be published on Github the full README will soon be published on Github the full LICENSE will soon be published on Github So... yes... that's just a short preview of an upcoming site profile. As mentioned before, the site profile will most likely never ever receive any future updates, so it will be available on Github only. It's not planned to publish this as a full featured site profile, yet. More details, screenshots and the site profile itself (of course) will be available soon. Questions? Please feel free to ask. Github Repository: https://github.com/webmanufaktur/pwbrestaurant

Try adding the classes in alphabetical order. { name: 'Left Aligned Photo', element: 'img', attributes: { 'class': 'float-md-left img-fluid' } }, { name: 'Right Aligned Photo', element: 'img', attributes: { 'class': 'float-md-right img-fluid' } }, { name: 'Centered Photo', element: 'img', attributes: { 'class': 'img-fluid w-100' } },

One of my client's website is running on Nginx : https://ricardo-vargas.com It works, but I think a better approach in most cases is to run Nginx as a reversed proxy with Apache serving the files, like I did for my other client: https://www.brightline.org. You get the benefits of easier configuration and a better performance (compared to only run Apache).

Well, the admin is built for that purpose to add and edit pages. Every user that has a login is able to see the admin, even if he can't edit anything and if he knows the url. Although you could add hooks to check for roles to redirect out of the admin in case. I didn't say use the module but look at it how it's done, it's also done using API (as everything in PW), so you would need that same codes anyway. I don't see any problems doing your own frontend forms based on a templates fields. But depending on the fields you need, it's not as easy as simply rendering the fields with a form wrapper and you're done (for the reasons mentioned). Jquery UI, inputfields css and scripts and the $config->js would also be needed for them, and some of them would be in the $config->scripts, $config->styles when you render fields on a page. I've never tried to rebuild the backend for the frontend, and always try to use some shortcut link on the pages for them to edit or create pages using a simple link with url to the right admin screen. If I combine that with &modal=1 and fancybox modal they don't even need to go to the backend. <a class="fancybox" href="/processwire/page/edit/?id=1123&modal=1">edit page</a> <a class="fancybox" href="/processwire/page/add/?parent_id=1022&modal=1">add page</a> That's in cases sufficient to give a simple frontend editing capability with 2-3 lines of code.