Robin S

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.

No, afraid not - it's for the PW admin.

Info here: https://github.com/processwire/processwire-requests/issues/173 You probably want FieldtypeDecimal (was a third-party module, now part of the core) for accurate decimal numbers.

That doesn't look like the correct syntax for setting multiple sorts in a selector string. I think it should be "sort=template, sort=-created" https://processwire.com/docs/selectors/#sort To apply it to the admin search using a hook: $wire->addHookAfter('ProcessPageSearch::findReady', function(HookEvent $event) { $event->return .= ', sort=template, sort=-created'; });

It's on the "Advanced" tab:

You don't have to implement anything, it's just stating the fact that the module initialiases Selectize when a select field is focused and destroys Selectize when that field is later blurred. And the reason this is done is to support any scenario where options are changed by JavaScript after the page loads. If Selectize was initialised the "normal" way (only once when the page loads) then it wouldn't work correctly after the options changed.

@joeck, this module might suit your needs:

This module enables Selectize (which is bundled with the PW core) on all Select and AsmSelect inputfields in the PW admin. As described below in the readme, Selectize is initialised/destroyed as the revelant select is focused/blurred in order to support select options that change after the page is loaded. Therefore Selectize is styled to match the AdminThemeUikit select as closely as possible to minimise the visual change as the select is focused and blurred. I'm developing on Windows so I'm not sure how the module will render on other operating systems. It doesn't help that the PW admin uses different fonts depending on the OS - I wish PW would bundle its own webfont for a standardised appearance everywhere. Incidentally, I was a bit disappointed with the state of the Selectize project. I had to fix or work around a number of bugs and shortcomings, including things you would think would just work out of the box such as disabled options, matching the width of the replaced select, or the standard select behaviour where a selection is required when there is no empty option. The Selectize issues repo is full of arbitrarily closed bug reports and pull requests and there are no updates for the last 6 years. I've tried to catch everything that would affect this module but I wouldn't be surprised if there are still some bugs. Selectize All Enables Selectize on all InputfieldSelect and InputfieldAsmSelect fields in the ProcessWire admin. The module activates Selectize on the <select> element when it is focused, and destroys Selectize when the element is blurred. This allows Selectize to work on selects where the options are changed dynamically after page load depending on other field values, e.g. the "Select File" field in the CKEditor link modal or a dependent select in Page Edit. Only AdminThemeUikit is tested and supported. Usage In the module config you can choose if Selectize should be used with InputfieldSelect, InputfieldAsmSelect, or both. If you want to disable the module for a specific Select or AsmSelect inputfield you can hook SelectizeAll::allowSelectize. This method receives the Inputfield object as the first argument. Example: $wire->addHookAfter('SelectizeAll::allowSelectize', function(HookEvent $event) { $inputfield = $event->arguments(0); // You can also get any associated Page and Field objects via $inputfield->hasPage and $inputfield->hasField // Disable the module for the inputfield named "template" if($inputfield->name === 'template') $event->return = false; }); https://github.com/Toutouwai/SelectizeAll https://processwire.com/modules/selectize-all/

https://paveldogreat.github.io/WebGL-Fluid-Simulation/ https://experiments.withgoogle.com/search?q=fluid

v0.2.0 of this module has been released, and because it is a fairly major rewriting of the module there are a couple of things to be aware of before upgrading: 1. The settings are no longer defined on the module config page, but rather in the field settings of each Repeater field: Setup > Fields > [your Repeater field]. If you visit the module config page you'll find shortcuts to the settings for each Repeater field. 2. In earlier versions you could apply restrictions to a particular role. This is still possible but is now handled by hooking LimitRepeater::checkRestrictions as this is a more flexible and powerful approach. If you were applying restrictions to a particular role or roles you'll need to add hook code to achieve the same effect after you upgrade the module. See the hook information in the updated readme.

The original image also uploaded fine for me with both the default and ImageMagick sizer engines.

Not sure I understand the question, but if you have a Page object (e.g. $page, $my_page) and you want to match it to a Page Reference field in a selector string the best way is to match by the page's ID. my_page_reference_field=$page->id Or you can actually just do... my_page_reference_field=$page ...because a Page object becomes an ID when it is treated as a string. Similarly a PageArray will become a pipe-separated string of IDs that can also be used directly in a selector string: my_page_reference_field=$my_page_array

This assumes that the "category" field allows for selection of a single page: $results = []; foreach($user->favorite as $item) { $category = $item->category->title ?: 'Uncategorised'; $results[$category][] = $item; } foreach($results as $category => $items) { echo "<h3>$category</h3>"; echo "<ul>"; foreach($items as $item) { echo "<li><a href='$item->url'>$item->title</a></li>"; } echo "</ul>"; }

Thanks @MoritzLost for the detailed post. One thing I don't understand and am hoping you might explain is how Craft handles field renaming within the project config file. Do the config files refer to fields by ID, name, or something else? It seems like IDs couldn't be used in the config because if the IDs auto-increment as fields are added then they wouldn't be consistent between installations. But if names are used instead of IDs then how is it declared in the config that, say, existing field "date" was renamed to "post_date", versus field "date" was deleted and a new field "post_date" was created? Because there's an important difference there in terms of whether data in the database for "date" is dropped or a table is renamed.

The most common way to use the "Add New" feature is by defining "Allowed template(s) for children" and "Allowed template(s) for parents" on the templates in question. See the information in the screenshot below: When you have this configured then you can quickly add new pages of the child template via the "Add New" button and menu link. The "Bookmarks" feature applies when you haven't defined allowed parent/child template settings, but you want a shortcut to add a new child page under some specific parent page. So if you had some deeply nested page that you often want to add new child pages under you could set a bookmark for that parent. Clicking the bookmark would then be the same as opening the page tree to that parent and clicking "Add", but it would perhaps save you some time. It's not a feature that I've found all that useful in practice.