Robin S

This seems to do the job: $wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) { /* @var InputfieldWrapper $wrapper */ $wrapper = $event->return; // Do some check on user role if($event->wire('user')->isSuperuser()) { $inputfields = $wrapper->getAll(); foreach($inputfields as $inputfield) { $inputfield->required = 0; } } });

You could use a hook... $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); /* @var Page $page */ $page = $event->arguments(1); if($page->template == 'your_parent_template') { $selector .= ", sort=date, sort=title"; $event->arguments(0, $selector); } }); ...or this module: https://modules.processwire.com/modules/process-page-list-multiple-sorting/

ProCache serves up a cached static HTML file using mod_rewrite rules in .htaccess It checks if... the request method is not POST there is no query string there is no wire_challenge or wires_challenge cookie a cached HTML file exists for the requested URL ...and if all of this is true it serves the HTML file. I recently opened a support topic asking for help using ProCache in conjunction with template cache (my site has a lot of logged-in users that I'd like to serve cached pages to). When Ryan replies over the weekend I'll mention the discussion here and ask if he'd consider improving the template cache using the principle you're experimenting with.

That sounds like a very good enhancement! It would be great to have a solution like this implemented in the core template cache, so it doesn't require any changes to a core file and is available to those not using AIOM+. An important factor is if enough information is known so early in the load process to deliver all the standard template cache features for things like multi-language, URL segments, logged-in users option and cache-disabling GET/POST vars. But a lot of that is knowable from the URL alone so I think your approach should work. If you have time, maybe you could experiment with this separate from AIOM+ and PM Ryan to see if he'd consider adding it to the core? If it works it would add another "selling point" to PW.

Sounds like the effects of a shortcut key combination. Maybe you have the Admin Hot Keys module (or something like it) installed?

Hi @matjazp, I'm not currently a user of this module, but I'm interested in this feature and your comments in the readme: What was the inefficiency you noticed in the core template cache feature and how did you make the AIOM+ cache more efficient? Is there an improvement that could me made to the core template cache that would be worth communicating to @ryan?

Building on @BitPoet's code, here's an alternative way you could add labels to the select options: $wire->addHookBefore('ProcessPageEditLink::execute', function(HookEvent $event) { $input = $event->wire('input'); $page = $event->wire('pages')->get($input->get->id); // Do some check on $page to return early when not applicable $anchors = $input->get->anchors ?: []; $my_anchors = [ 'some_anchor' => 'Some anchor', 'other_anchor' => 'Other anchor', 'third_anchor' => 'Third anchor', ]; $anchors = array_merge($anchors, array_keys($my_anchors)); $input->get->anchors = $anchors; $event->wire()->addHookBefore('InputfieldSelect::render', function(HookEvent $event) use ($my_anchors) { $inputfield = $event->object; if($inputfield->name !== 'link_page_anchor') return; $options = $inputfield->options; $inputfield->options = []; foreach($options as $option) { $anchor_name = ltrim($option, '#'); if(isset($my_anchors[$anchor_name])) {; $inputfield->addOption($option, $my_anchors[$anchor_name]); } else { $inputfield->addOption($option); } } }); });

Perhaps a typo or other error in your code. I use $files->render() regularly and can pass in objects without any problem.

When you pass in variables to $files->render() as ['myVar1' => $var1, 'myVar2' => $var2] then they are available in the rendered file as $myVar1 and $myVar2.

This is already possible with two lines of code, so I don't think a dedicated method is needed. $s = $modules->get('InputfieldSubmit'); $s->attr('disabled', true); $s->addClass('ui-state-disabled');

So long as you don't have a custom sort setting on the parent template or parent page (i.e. the pages are just sorted according to the default which is "Manual drag-n-drop") then you can compare the "sort" value of the pages. if($sibling_1->sort > $sibling_2->sort) { // $sibling_1 is after $sibling_2 in the page tree }

Thanks, but not necessary. Pretty much all my modules get created because I have a need for them in work that I get paid to do, and it doesn't cost me anything to make them available for others to use too.

v0.3.0 released. Notable changes in this version: 1. Fix for page clone issue reported by @a-ok in the post above. 2. The module now hooks Pages::save() and Pages::saveField() instead of Pages::saveReady() and Pages::saveFieldReady() in order to work around this core issue. Hopefully that issue gets resolved and then the module can go back to saveReady hooks because those would be preferable, but for now something had to be done because the issue was making page changes unsaveable when "single" Page Reference fields were configured in this module.

Have you tried it? There is already support for strtotime strings for datetime fields in PageFinder selectors, and your example query works just as you wrote it. ? For in-memory (WireArray) selectors you have to use a timestamp in the selector.

You cannot have two pages that reference each other via "single" Page Reference fields: https://github.com/processwire/processwire-issues/issues/572 Also watch out for: https://github.com/processwire/processwire-issues/issues/1092 Workarounds include the Page IDs module or use "multiple" Page Reference fields instead of "single". I feel that the convenience of getting a Page object back as the value of a single Page Reference field is sadly outweighed by the frustration of these issues. I'd rather just get an ID that a Page object can then be loaded from if/when needed.

If you are regularly building new sites you might want to consider creating a "default" profile that you install as the starting point of each new project. The idea is that you start with the core "blank" profile and... install any modules that you tend to use in every site configure everything the way that you want (module configs like the one mentioned above, /site/config.php settings, etc) create any template files that are always needed (e.g. _init.php and _main.php depending on your output strategy) ...then export that profile with Site Profile Exporter. Now when you start a new project you install PW with this default profile and everything is set up how you like it to be. Different folks have different strategies but this one works well for me.

https://processwire.com/blog/posts/processwire-3.0.107-core-updates/#trash-for-all

I think you edited your original post and topic title, right? My answer was for the original question and isn't relevant now that you've changed it. Better to mark a topic as solved and start a new topic in such situations I think.

Give this a try: // Create WireUpload instance (it doesn't matter what name you give it) $wu = new WireUpload('foo'); $file_path = '/the/path/to/your/image.jpg'; // Get the basename only $basename = basename($file_path); // Sanitise basename the same as would be done if the file was uploaded via admin $sanitised_basename = $wu->validateFilename($basename); // Look for an existing file with that sanitised basename $existing_file = $page->images->get($sanitised_basename); // Add the file if it doesn't exist if(!$existing_file) $page->images->add($file_path);

There's no magic option - you have to code your own search in the way that suits you. If the number of search results is not huge and pagination is not required then you can get all the results where any field matches, and then divide off the pages that have matches in the title field, rendering those results before the others. Otherwise you might want to use an SQL query, perhaps returning just an array of page IDs which you could then slice according to the pagination number and load to a PageArray via $pages->getById().

@Jozsef, I'm not sure but the failure to save changes and the fact that the order pages you are getting have a reference to the current page being saved makes me think it could be this issue: https://github.com/processwire/processwire-issues/issues/1092 But as far as I know this issue should only occur if you get the value of the order_event field (i.e. the page that is currently being saved) and I don't see that in your code. If you have "Autojoin" enabled for that field this could also cause the issue.

@Marco Ro, you can use InputfieldWrapper::setMarkup() to customise the markup of inputfields. See the defaultMarkup property as a starting point for what can be customised: /** * Markup used during the render() method - customize with InputfieldWrapper::setMarkup($array) * */ static protected $defaultMarkup = array( 'list' => "<ul {attrs}>{out}</ul>", 'item' => "<li {attrs}>{out}</li>", 'item_label' => "<label class='InputfieldHeader ui-widget-header{class}' for='{for}'>{out}</label>", 'item_label_hidden' => "<label class='InputfieldHeader InputfieldHeaderHidden ui-widget-header{class}'><span>{out}</span></label>", 'item_content' => "<div class='InputfieldContent ui-widget-content{class}'>{out}</div>", 'item_error' => "<p class='InputfieldError ui-state-error'><i class='fa fa-fw fa-flash'></i><span>{out}</span></p>", 'item_description' => "<p class='description'>{out}</p>", 'item_head' => "<h2>{out}</h2>", 'item_notes' => "<p class='notes'>{out}</p>", 'item_detail' => "<p class='detail'>{out}</p>", 'item_icon' => "<i class='fa fa-fw fa-{name}'></i> ", 'item_toggle' => "<i class='toggle-icon fa fa-fw fa-angle-down' data-to='fa-angle-down fa-angle-right'></i>", // ALSO: // InputfieldAnything => array( any of the properties above to override on a per-Inputifeld basis) ); There are still some limitations (e.g. item_label is always rendered before item_content) but you can get closer to what you want like so: InputfieldWrapper::setMarkup([ 'list' => "<div {attrs}>{out}</div>", 'item' => "<div {attrs}><div class='InputfieldContent'>{out}</div></div>", 'item_label' => "<label class='{class}' for='{for}'>{out}</label>", 'item_content' => "{out}", 'item_toggle' => "", ]); $form = $modules->InputfieldForm; $f = $modules->InputfieldText; $f->name = 'greeting'; $f->label = 'Greeting'; $form->add($f); $f = $modules->InputfieldSubmit; $form->add($f); echo $form->render(); If I understand right you don't really need to change the markup to do this. The label element can never literally be inside the input element, but you can position it overlaying the input using CSS with the default markup. .Inputfield { position:relative; } .InputfieldHeader { position:absolute; left:5px; top:3px; font-size:12px; text-transform:uppercase; } input[type=text] { padding:17px 5px 5px; border:1px solid #ccc; } .InputfieldSubmit { margin-top:20px; } If you want to change the label styling when the input is focused you can use some JS to add a class to the parent .Inputfield element when its child input is focused.

Oh right, I was thinking about InputfieldSelector in the context of Lister. You just set the value of the inputfield: $f = $this->wire('modules')->InputfieldSelector; $f->name = 'test_selector'; $f->label = 'Test InputfieldSelector'; $f->value = "template=news_item, colours.title=Blue";

There is some example API code in a post above:

Use the defaultSelector property instead of initSelector if you want the user to be able to see (and therefore change) the selector in the filters section.