Robin S

@MarkE, the SelectizeAll module itself doesn't get involved with the change event. The problem is likely to be an incompatibility between the Selectize and htmx libraries. I can't do much about that, but in the newly released SelectizeAll v0.1.2 you can disable the module for an inputfield by giving it a "no-selectize" class. So when you create a select or AsmSelect inputfield in your module you would add a line like this... $inputfield->addClass('no-selectize'); ...and then if the two modules are used together your selects/AsmSelects won't be "selectized".

As a side note, if the new site is an enhancement of the old site (rather than a totally new site built from scratch) and you have PagePathHistory installed (a must-have on every site) then you should be able to move the existing news articles to any new path and PW will automatically redirect visitors from the old location to the new location. But if it's a new site from scratch where the IDs of historical news articles are now different to the old site, then I suggest doing the redirects using the PW API rather than manually entering a long list of redirects in htaccess. There are different ways you could do it. You could hook ProcessPageView::pageNotFound or use URL segments on the template for the /news/ page. Both would be fine, but I think the latter is a bit easier. Enable URL segments on the template for the /news/ page, and at the top of the template file: // If there is a URL segment (i.e. no real page exists at the requested URL) if($input->urlSegment1) { // Check for a published news article with that name $article = $pages->findOne("template=your_news_article_template, name=$input->urlSegment1"); if($article->id) { // If match found then redirect $session->redirect($article->url); } else { // Otherwise throw 404 throw new Wire404Exception(); } } // Only one segment is allowed if($input->urlSegment2) throw new Wire404Exception();

Does the field have the "Required" checkbox checked?

Open the page tree to Admin > Access > Roles and open the Roles page for editing. Temporarily uncheck the "Locked" status on the Settings tab and save. On the Children tab, in Sort Settings, choose "name" in the "Children are sorted by" dropdown. Save. Now re-check the "Locked" status and save.

I don't think that will work because the page will also be saved immediately after it is created and so the hook would just delete it before it can be edited. I suggest you just clean up abandoned pages on a regular shedule using LazyCron. First install the module at Modules > Install > LazyCron. Then add a hook like this to /site/ready.php: // Once per day $wire->addHook('LazyCron::everyDay', function(HookEvent $event) { // Find pages that appear to be abandoned because they still have the default title 24 hours after creation $time = strtotime('-24 hours'); $abandoned_pages = $event->wire()->pages->find("template=your_template, title='New Owner', created>$time, include=all"); // Trash the abandoned pages foreach($abandoned_pages as $abandoned_page) { $abandoned_page->trash(); } }); You could delete the pages if you like but maybe safer to trash them and then just empty the trash once in a while.

I'm surprised you have so many template variables to declare. You might like to take a look at Markup Regions because that should greatly reduce the number of variables you need to hold markup. Does the below work? (P.S. parentheses are redundant for include, include_once, etc because they are expressions rather than functions) include_once './_func.php'; include './_header.php'; include './_sidebar.php'; include './_footer.php'; include './_buttons.php';

I use generic words and numbers for field names, e.g. text_1, textarea_1. I really wish I didn't have to do this and could use descriptive names for fields, but the problem is that I almost always want to reuse fields for different purposes on different templates. So while a name like "city" is more meaningful than "text_1", I think it's much more confusing to call $page->city in some template when that field is actually holding a person's job title or something totally unrelated to "city". What I'd like is for PW to support field aliases, so that in the context of the "store" template I can give text_1 the alias of "city" and in the "employee" template I can give text_1 the alias of "job_title". Field aliases would need to be unique and in practice you could refer to a field by any of its aliases in any place in your code. I have an open request for this: https://github.com/processwire/processwire-requests/issues/154 Ryan seemed supportive at the time but it hasn't progressed anywhere since 2018. If anyone else would like this feature please "vote" for it with a thumbs-up at GitHub. I've also created a module that would allow aliases to be used but it can't be released due to issues with FileCompiler: https://github.com/processwire/processwire-issues/issues/882

I think a better way is to skip the Add Page step and then make sure the title is always automatically derived from your two fields when they are populated. There are a few steps involved, illustrated here with case that is different to yours but you can see the similarity. In this example the template of the parent page that new pages are added under is named "creatures", and the child template (where the title is being set automatically) is named "creature". 1. For the "creatures" template, make sure that it allows a single template for children: the "creature" template. 2. For the "creatures" template, in the "Name format for children" setting enter "Y/m/d H:i:s". This will allow the "Add Page" step to be skipped and will automatically set the page name to the current date and time. We will later change the name in a hook. 3. Optional but recommended: for the "creature" template, choose the "creatures" template as "Allowed template(s) for parent". This lets you quickly add child pages via Pages > Add New and also ensures that new pages can't be added in the wrong place. 4. For the "creature" template, edit the Title field in the template context and set the visibility to "Open when populated + Closed when blank + Locked (not editable)". The title is going to be set automatically so editors should not be able to change it manually. 5. Add hooks like the ones below to /site/ready.php. // Pages::added $pages->addHookAfter('added', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // Creature if($page->template == 'creature') { // This is a newly added page so the fields that make up the title won't be populated yet $page->setAndSave('title', 'New creature'); } }); // Pages::saveReady $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); /** @var Pages $pages */ $pages = $event->object; // Creature if($page->template == 'creature') { // Return early if the page is in the trash (thanks @taotoo) if($page->isTrash) return; // If the fields that make up the title are populated if($page->colour->id && $page->animal->id) { // Set the title $page->title = "{$page->colour->title} {$page->animal->title}"; // Sanitize the title as a page name $name = $event->wire()->sanitizer->pageName($page->title, true); // Set the page name while making sure it auto-increments if there is a sibling page with the same title $page->name = $pages->names()->uniquePageName($name, $page); } } }); Result:

It's explained in this post: Try separating functions from declared variables. See how it is done in the core site-default profile: https://github.com/processwire/processwire/blob/d78276e2c265f6b70384a13eb4febd4811a1db77/site-default/templates/_init.php Put all your functions in a file that is pulled in with include_once. Declare your variables in _init.php.

@MarkE, thanks for the report. Please try the updated v0.3.4.

It might work as a selector string: template=my_Template, field_in_my_Template=page.parent.title Or if field_in_my_Template is a Page Reference field: template=my_Template, field_in_my_Template=page.parent

The "Multiple page selection" version of Page Auto Complete doesn't support the "Custom PHP code" option (i.e. the InputfieldPage::getSelectablePages hook). In earlier versions of PW it used to be more explicit about that. Now it just removes the "Custom PHP code" option depending on what you have selected in "Input field type". Page List Select and Page List Select Multiple also do not support the "Custom PHP code" option. If you really are returning something like that from you hook then you could change to the "Selector string" option, which will work with autocomplete.

I am, but only on a single site and it's for a feature that's only activated once a year for a short period (an annual vote). I think I might have a use case for the module in some updates to a site that will be happening in the coming months. When that happens I'll spend some more time getting familiar with the module and can submit any ideas that come out of that. Thanks.

@monollonom, you could do this with a hook in /site/ready.php: $wire->addHookAfter('InputfieldRepeater::renderReadyHook', function(HookEvent $event) { /** @var InputfieldRepeater $inputfield */ $inputfield = $event->object; // Disable RepeaterEasySort on all Repeater fields apart from those named "foo" if($inputfield->hasField && $inputfield->hasField->name !== 'foo') { $inputfield->removeClass('RepeaterEasySort', 'wrapClass'); } }, [ 'priority' => 101 ]);

It's not only JavaScript, sometimes it's the design of our backend...

The JS is missing a call to initialise the datepicker when a field is reloaded (e.g. when an ajax-loaded Repeater item is opened). You could open a GitHub issue if you like. InputfieldDatetime.js needs something like this added: $(document).on('reloaded', '.InputfieldDatetime', function() { var $input = $(this).find('input.InputfieldDatetimeDatepicker:not(.InputfieldDatetimeDatepicker3):not(.initDatepicker)'); if($input.length) InputfieldDatetimeDatepicker($input); });

1. If it's your code that's putting the repeater page IDs into session then you can count on them being what you expect and you don't necessarily have to validate them against a template or a repeater field. So you could just do... $item = $pages->get($id) ...or... $item = $pages($id); 2. It's because in the first case the selector is going to the database via PageFinder and in the second case the selector is searching within a PageArray in memory. There are a number of differences between what is possible with these two kinds of selectors but unfortunately those differences aren't described in the official documentation. Some related posts: https://processwire.com/talk/topic/16067-find-repeater/?do=findComment&comment=148983 https://processwire.com/talk/topic/18343-selector-filter-for-multiple-dates/?do=findComment&comment=160451 https://processwire.com/talk/topic/20143-selector-is-case-sensitive/ 3. For your Page Reference field you can use something like this as the "Selector string" for selectable pages: id=page.your_repeater_field_name Or you could use the Custom PHP option: $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { $page = $event->arguments('page'); if($event->object->hasField == 'your_page_reference_field_name') { $event->return = $page->your_repeater_field_name; } }); If you add new repeater items you'll need to save the page before you can select them, because PW doesn't know they exist until you do that.

ProFields Table doesn't provide this as a feature. I requested it in 2015 and it has been on the "todo" list since then, with occasional re-requests from other users. Topic in the Pro support forum: Would be great if anyone who wants the feature could remind Ryan about it. Until the feature is part of the official ProFields Table, here is a module that does the job... Table Column Required Adds a "required" option for columns within ProFields Table. Saving a page with an empty required column will alert the user via error messages and highlight the relevant table cells. But it doesn't implement any non-default action set at Template > Advanced > "Required field action". Paginated tables are supported. Screenshots Page Edit Field config https://github.com/Toutouwai/TableColumnRequired

First, it's probably best not to try and host such a site on shared hosting. If the site is that popular the client should be able to afford better hosting. You could try using mysqldump in a cron job and see if that works. Example: mysqldump -u'YOUR_DATABASE_USERNAME' -p'YOUR_DATABASE_PASSWORD' YOUR_DATABASE_NAME > /home/YOUR_ACCOUNT/public_html/site/assets/backups/database/YOUR_DATABASE_NAME_`date +\%Y\%m\%d_\%H\%M`.sql

@prestoav, uploading a file is something different. The code I posted was for moving files that already exist on the page between fields. There are lots of tutorials out there for how to create a file upload form and process it with PHP. Here is one: https://code.tutsplus.com/tutorials/how-to-upload-a-file-in-php-with-example--cms-31763 When you process the form input you'll want to move the uploaded file to the page's directory (you can use PagefilesManager to get the path) and then you'll be able to add the file to $pageimages using its path. PW has the WireUpload class which can be useful for handling file uploads. If you search the forums you'll find examples.

Very nice! In the context of this post in the PW forums I find myself looking for a link to your site so I can see the search in action. Maybe you could add a link? A tip: str_replace() accepts an array for the $search argument, so your stripText() function could be made more compact where it is removing multiple different characters.

I can reproduce the issue. Please open a GitHub issue so that Ryan can investigate. As you say, there seem to be two things needing attention: The description for the Tags inputfield on the Advanced tab of Edit Field should state the range of characters that are allowed in a tag (umlauts and other accented characters are not allowed). If a disallowed character is added via that Tags input it should be sanitized out to avoid breaking InputfieldTextTags. Disallowed characters are already sanitized out when adding a tag via Manage Tags > Add new tag.

Weird though, because the non-superuser should be dealing with fewer results so if anything I would expect it to be faster. I wonder if there's any relation to the weird slow query issues that @adrian has reported recently. https://github.com/processwire/processwire-issues/issues/1523 https://github.com/processwire/processwire-issues/issues/1535

It works for me. Template file: <?php namespace ProcessWire; header('Content-Type: text/calendar; charset=utf-8'); header('Content-Disposition: attachment; filename="my-file.ics"'); ?> BEGIN:VCALENDAR VERSION:2.0 PRODID:-//ZContent.net//Zap Calendar 1.0//EN CALSCALE:GREGORIAN METHOD:PUBLISH BEGIN:VEVENT SUMMARY:Abraham Lincoln UID:c7614cff-3549-4a00-9152-d25cc1fe077d SEQUENCE:0 STATUS:CONFIRMED TRANSP:TRANSPARENT RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=2;BYMONTHDAY=12 DTSTART:20080212 DTEND:20080213 DTSTAMP:20150421T141403 CATEGORIES:U.S. Presidents,Civil War People LOCATION:Hodgenville\, Kentucky GEO:37.5739497;-85.7399606 DESCRIPTION:Born February 12\, 1809\nSixteenth President (1861-1865)\n\n\n \nhttp://AmericanHistoryCalendar.com URL:http://americanhistorycalendar.com/peoplecalendar/1,328-abraham-lincol n END:VEVENT END:VCALENDAR Result: Make sure you're not prepending or appending any other file to the template that could be messing things up (including automatic prepend/append in $config).

I had actually just given an answer regarding that in the post immediately above yours: But okay, it sounds like you have a real need for this, so v0.2.0 adds an option to have easy-sort mode active by default. It also adds mode buttons to the field header. See the updated readme for more information.