BitPoet

Since Latte is a composer package, I'd assume you should require_once '../modules/RockFrontend/vendor/autoload.php' to make sure all dependencies of Latte\Engine are included as well.

Looks like a perfect application for LazyCron. A quick and dirty snippet of code you can place in site/ready.php (or inside a template's PHP file, just make sure that a page with that template is viewed regularly): <?php namespace ProcessWire; // Add daily hook to clean up incomplete, stale pages wire()->addHook('LazyCron::everyDay', null, function(HookEvent $event) { $ts = time() - 86400; // 24 hours ago // Find matching pages, adapt selector however you want (e.g. limit to certain templates or parents) $stalePages = $pages->find("created<$ts, title=''"); foreach($stalePages as $stalePage) { $pages->trash($stalePage); } });

This is because Page Autocomplete doesn't use InputfieldPage::getSelectablePages. Instead, it sends a live query to ProcessPageSearch. Unfortunately, this means that the field settings are written to the JS config, and support for selectors is somewhat limited there. There's been a github issue around for some time with a workaround, which unfortunately means adding a few lines to a core js file, so it needs to be reapplied after every update: https://github.com/processwire/processwire-issues/issues/1374#issuecomment-835032978

Glad to hear my suggestion works. Don't bother about that text in notifications. It's part of a default mail template, but the option to mark solutions isn't enabled in the forum.

Does calling $pages->uncacheAll() before deleting your process page fix it? Since $page->delete takes an option argument for recursion. So you could just call $webshop->delete(true) and forgo deleting orders and their parent page individually.

The "published" hook is in the Pages class. So it should look something like this: $wire->addHookBefore('Pages::published', function($event){ $page = $event->arguments(0); if($page->template->name !== 'templateName') return; $this->message("the Hook has been called"); if($page->hasField("myDateField")) { $newDate = date("d.m.Y"); // Need to call "save" explicitely after publishing since saving is already done by then. // Wrapped it all in a single call, not changing modified user and timestamp again $page->setAndSave('myDateField', $newDate, ['quiet' => true]); } }); You could consider hooking Pages::publishReady instead and set your myDateField there, that would save you the second write to the database.

It's pretty straight forward. Instead of defining textual options, you create a page for every selectable option. Preferably, you group them under their own parent, and you'll usually want to assign them their own template, both to make queries easier and so you can add more fields to the template later. In your case, you can start with a (backend-)template "region", no need to add a PHP template file since the region pages are only for filling the dropdown. You'll also want a template "regions" for the regions' parent page. This one will be the overview page you're trying to build and therefore need a PHP template. In the first step, just create both templates with the minimum fields PW suggests (i.e. just a "title" field which will be the label in your dropdown). Then create the pages. Home - Regions - - Region 1 - - Region 2 - - ... In your hotel template, add a page reference field for the region, and on the "Input" tab in the field's configuration, go to "Selectable pages". Under "Templates", select "region". Edit your hotels and assign a region to each. Now you can easily iterate over all available regions in your regions.php template file, output the region's details and a list with the hotels for that region. A little PHP snippet as a starting point: <?php namespace ProcessWire; foreach($page->children() as $region) { echo "<h3>{$region->title}<h3>"; echo "<ul>"; $hotels = $pages->find("parent=/hotels/, region=$region"); foreach($hotels as $hotel) { echo "<li><a href='{$hotel->url}'>{$hotel->title}</a></li>"; } echo "</ul>"; }

How is your region dropdown defined? Is it a page reference field? (I'm asking because if it is, it'll be a lot more straight forward than if you used an options field).

I'm not completely sure, but the hook could easily copy values from the FieldsetPage to a new repeater item if that is needed. The field names will be identical, so it'll just be a loop like foreach(['name','phone','email',...] as $fieldname) { $newItem->$fieldname = $page->myFieldsetPage->$fieldname; }

If the first item isn't to be moved, it might be easiest to just add a fieldsetpage field containing the same fields as the repeater minus the select option.

Untested, but have you tried a showIf condition of sort>0?

This seems to imply that the version of FieldtypeFile in memory is still at 3.0.146, since getValidFileExtensions was added in release 3.0.167. Clean out site/assets/cache/FileCompiler and make sure that FieldtypeFile is in fact found at wire/modules/FieldtypeFile.

Have you tried "alojamiento_combo.category.name=$segmento1"? If that doesn't work, then, as far as I understand the docs, you'll probably need to convert the name in your URL segment to a full path (e.g. "/categorias/domo/" or wherever in your structure the category is located). The docs say: You could of course retrieve the category in a separate query and use the return in your selector. $categoria = $pages->get("template=categoria, name=$segmento1"); $filter = $pages->find("template=alojamiento, alojamiento_combo.categoria=$categoria, sort=random, limit=20");

That's how it should be. Have you called $image->removeVariations() in between or added "forceNew" => true to your $options when calling $image->size(), to make sure the thumbnail is created from scratch?

That's what ModuleName.info.php was designed for. PW can check dependencies without loading the full module.

I'd say, not much, just that the the "current" page in the dashboard is the page "/processwire/page/edit", not the page actually being edited, that's why trashing in the backend works. Your analysis is otherwise spot on, I was about to write the same. I'd suggest to raise another, more specific, issue on github. I don't see any reason not to trash the current page if the very next step is a redirect.

Can't you use the "Extra Allowed Content" line in the field's settings?

How about adding a meaningful log output everywhere you read or assign your session variable? The log lets verify in which order those are executed, which page calls they come from, and if there's maybe an execution step you didn't think of. In the more complex developments, I like to make such log output conditional on $config->debug. <?php namespace ProcessWire; $session->set( 'event_number', $n ); if($config->debug) $log->save('eventnum', "Wrote event number $n to session"); //....... $evtnum = $session->event_number; if($config->debug) $log->save('eventnum', "Read event number from session: $evtnum");

No, it isn't, unless you explicitly disabled FileCompiler in your config.php. Otherwise, it's usually a sign that the permission for your site/assets/FileCompiler folder are wrong (or even that the web server instance is running with a different user/group id than previously and lacking write access - on shared or cloud hosting, switching PHP versions could also mean switching web server instances).

It definitely is. WireArray::filterData, which is responsible for executing the selector, does an explicit cast to (string) on the value. So it ends up with a literal "Array" instead of the values in childTemplates. This has the funny side effect that $templates->find('childTemplates=Array'); returns all templates. I'd call it a bug, since filterData seems to assume that all array-like values stringify to a pipe separated list like WireData, yet Selector::matches can deal with array values just fine. But since templates are loaded into memory anyway, you can just iterate over them and do a manual comparison without a performance or memory penalty. <?php namespace ProcessWire; $matched = []; foreach($templates as $t) { if( count(array_intersect($templates->childTemplates, [29,30])) ) $matched[] = $t; }

It's not configurable, since the module config doesn't show system fields, but you can add them permanently with this little snipped for site/ready.php: <?php namespace ProcessWire; wire()->addHookBefore('ProcessUser::execute', function(HookEvent $event) { $process = $event->object; $process->showFields = array_merge($process->showFields, ["created", "modified"]); }); For changing the date format to something more precise, you can hook into the lister: <?php namespace ProcessWire; wire()->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { $page = wire('page'); // Only continue if we're actually listing users in the backend if($page->process !== 'ProcessUser') return; $lister = $event->object; // Assign whatever date format you like $lister->nativeDateFormat = 'Y-m-d H:i'; });

In that case it's pretty straight forward: Create a new field of type "Integer" for holding your allergen number, I'll call it 'allergennumber' here Add the field to the template for your allergens Assign a number to the existing allergens in page editor In the configuration of your page select, on tab "Input", field "Label field", select the "Custom format (multiple fields)" option In the "Custom page label format", enter "{allergennumber} {title}" Your checkboxes will now show numbers. Now for the automatic part for new allergens. Let's assign the highest existing number plus one to every newly created page with template allergen. For that, I'll assume that the template is named "allergen". The PHP code goes into site/ready.php and is executed every time before a page is saved: <?php namespace ProcessWire; wire()->addHookAfter('Pages::saveReady', function(HookEvent $event) { $page = $event->arguments(0); // Adapt the template name to your naming if($page->template->name !== 'allergen') return; // Only fill the field allergennumber for new pages if(! $page->isNew()) return; // Let's get the allergen page with the highest existing number $maxNumPage = $pages->findOne('template=allergen, sort=-allergennumber'); // Just in case we're starting from scratch, handle the first allergen page $maxNum = ($maxNumPage instanceof NullPage) ? 0 : $maxNumPage->allergennumber; // Increment by 1 and set the new page's allergen number $page->allergennnumber = $maxNum + 1; });

It's definitely doable (almost anything is in PW), but before suggesting an approach, I feel like asking a few questions. Are these numbers to be static, i.e. does a page always have to have the same number in front? Can the pages in question be deleted or resorted, and what happens to the numbers then?

It's because of a bug in TextformatterHannaCode.

Thanks for the feedback. An unfortunate side effect of InputfieldPageListSelect is that it doesn't have an easy way to disable individual items in the tree for selection, and checking after the data is submitted feels a bit clunky. I'll try to find a hopefully intuitive way to add the check, but it may take a little while.