Robin S

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.

Well, I couldn't help myself. ? Plus it wasn't as bad as I expected. @Didjee, the insert buttons and other features from Repeater Matrix v7/8 should work in the newly released Restrict Repeater Matrix v0.2.0.

It's not just the new insert before / insert after features, it's also all the new options for adding items that would need attention. It looks like a lot of work to support and probably it still won't work reliably for all the options, e.g. custom. Sorry, but it's unlikely I'm going to get around to spending the time on this in the foreseeable future. It's probably not practical for a module like Restrict Repeater Matrix to exists when the base module (Repeater Matrix) can be changed at any point. Repeater Matrix is a commercial module so Ryan should be responsive to the needs of its users - I suggest submitting requests to Ryan for the features you want to see. I'll add a note at the top of the readme about the incompatibility with recent updates to Repeater Matrix.

Fair enough, I've added support for more custom labels in v0.2.1.

Thanks, should be fixed in v0.2.2

I can't reproduce that. The column configuration I used for testing: Screencast: Is pagination turned on for your Table field by any chance? Can you provide steps for a basic test case where the problem occurs?

I agree that the drag cursor isn't needed here. I don't like the idea that any click on the image would delete it, but what I've done in v0.2.0 is that when the max items is set to one and an image is already selected in the inputfield then the button is labelled "Replace image..." so that the next selected image will replace the existing image with a minimum of clicks.

You could use Option C: https://processwire.com/docs/front-end/front-end-editing/#option-c-html-edit-tags <edit field="title,link,text" page="4302"> ... </edit>

Thanks, should be fixed in v0.1.2.

The trick is to put all the affected images into a new Pageimages object before you start setting the field values, so you can later get each image from there even after it has been removed from a field value. A proof of concept... Image fields in Page Edit: Tempate file markup: <script src="/site/templates/js/jquery-ui.min.js"></script> <script> $(document).ready(function() { var $sortable_images = $('.sortable-images'); $sortable_images.sortable({ // When any image has been moved... update: function(event, ui) { // Add the image basenames to an array in the new order var value = []; $sortable_images.find('img').each(function() { value.push($(this).data('filename')); }); // Join to a comma separate string and set as the form field value $('#images').val(value.join(',')); } }); }); </script> <div class="sortable-images"> <img src="<?= $page->image_1->size(150,150)->url ?>" data-filename="<?= $page->image_1->basename ?>" alt=""> <img src="<?= $page->image_2->size(150,150)->url ?>" data-filename="<?= $page->image_2->basename ?>" alt=""> <img src="<?= $page->image_3->size(150,150)->url ?>" data-filename="<?= $page->image_3->basename ?>" alt=""> </div> <form id="image-order" action="./" method="post"> <textarea name="images" id="images"></textarea> <button>Submit</button> </form> Template file PHP: // Look for the comma separated value in POST $images_value = $input->post('images'); // If the value exists then the form was submitted if($images_value) { // Explode the comma separated value to an array of image basenames $image_names = explode(',', $images_value); // Create a Pageimages object using the individual image basenames $all_images = new Pageimages($page); foreach($image_names as $image_name) { $all_images->add($image_name); } // Turn off output formatting because we are about to set field values $page->of(false); // Loop over the image basenames foreach($image_names as $index => $image_name) { // Get the Pageimage from $all_images $pageimage = $all_images->get($image_name); // Create a new empty Pageimages object $pageimages = new Pageimages($page); // Add the Pageimage $pageimages->add($pageimage); // Determine the field name that will be updated $image_field_name = 'image_' . ($index + 1); // Set the field value $page->$image_field_name = $pageimages; } // Save the page $page->save(); // Redirect back to the page (Post/Redirect/Get pattern) $session->redirect($page->url); }

Sounds good to me, because although the cached pages are expected when you know how PW goes to the cache first before loading pages from the DB this might not be common knowledge and the expectation is probably that the Console is a "blank slate".

You nailed it! I was trying that code from the Tracy Console while viewing the page in Page Edit, and so must have been getting the cached version of the page that was already loaded. If I use the Console on a different page or preceed the code with $pages->uncacheAll() then it works as expected. Thanks!