Robin S

That looks cool. Is only Nginx available or is Apache an option?

If you want your hook to fire on the saving of all pages but the one you are updating in your hook you would do: public function UpdateAnotherPage($event) { $page = $event->arguments('page'); if($page->id !== 1240) { // update page 1240 } }

You misunderstand what I'm saying: you are hooking page save, but saving a page inside your hook - that recurs indefinitely.

You are missing the crucial step in your hook where you check what page was saved and then decide if you want your page update code to run. You don't want that update to occur on any page save like it does now, because then it will trigger again when the updated page is saved in the hook, and so on until the cows come home.

It's possible, but I don't think there is a way to limit the access to a single module. Module configuration uses the ProcessModule process. If you check the source for that class you can see the permission that is needed to get access to the process: 'module-admin'. So you can create that permission and give it to a role, but then they can configure any installed module, which would be quite dangerous. Also, the modules menu still doesn't appear for the role - you'd have to dig around in the admin theme modules to find out what prevents that menu item from rendering. An alternative would be to create a custom Process module that provides the same config fields and then save to the MarkupSEO config on page save. Then you can give access to that one Process module.

What is actually happening when you upload larger files? PHP error message? Any JS errors in the browser console? Do you have debug mode on and Tracy Debugger installed and activated for the back-end?

This jQuery plugin seems to do the job without any obvious performance issues: http://laertejjunior.github.io/freezeheader/

Re-reading the docs, I'm not sure why Ryan advises against using option B with Repeaters or PageTables (for Files/Images fields it makes sense). Maybe he means if you are wanting to make the entire Repeater/PageTable field editable rather than the individual fields inside the items, because it does seem to work fine for the latter case (once the access bug is worked around).

Why is it a lot of extra effort? There's not that many field classes, and you would know which are in use in your installation and just check for those, for each returning the data that suits that class.

Strings and arrays are different types of data, and a PageArray is a actually an object but you can think of it as a special kind of array. Long story short, you can't use PageArray methods on a string. It's difficult to help without seeing the code where you set the $pageArray variable.

Welcome @VirtuallyCreative! substr() is the function that is usually used to get a portion of a string in PHP. substr($page->title, 0, 2)

Looks like internally $sanitizer->date() is relying on strtotime() to check that the date is valid, and this function for some reason returns a timestamp for '2017/02/31' rather than 'false'. It should perhaps be changed to checkdate() which correctly identifies that date as invalid. In the meantime you could add an extra validation: function validate_date($value) { $parsed = date_parse($value); return checkdate($parsed['month'], $parsed['day'], $parsed['year']); }

I think you can do this with core PW fields, and enhance it with some custom JS if you want. Here's what I'm thinking... You have your Place pages in their own branch of the tree. The Place template has a repeater field "Offers" where all the possible offers for that Place are defined. Then you have a repeater field "Places" on your Partner template. You add two Page Reference fields to the repeater: 1. "Place", which is a single select field limited to the Place template. 2. "Choose offers" which is a multiple AsmSelect field using a "Custom PHP code" hook. The hook will return the value of the "Offers" repeater field (which will be a PageArray) for the place that is selected in the "Place" field. Now this hook is a bit trickier than normal because your Page Reference fields are inside a repeater and so you don't want $page to be the page being edited, but rather the repeater page that contains your fields. So in the hook you need to get the inputfield name and extract the ID integer portion of it and use that to get the $page object. I can explain more about this if you decide to go down this road. So this approach should work but it will require editors to save the page after choosing a place in the "Place" select, before they can choose offers for that place. If you wanted to enhance it a bit more you could have the "Choose offers" field allow all offers pages (limit using the Offers repeater template rather than a custom PHP hook) and then use some custom JS in admin to empty the inputfield options on load and on change of the "Place" select it gets the offers for that place via AJAX and populates the "Choose offers" options.

Issue has been opened on GitHub: https://github.com/processwire/processwire-issues/issues/183

It is only option D that forces the modal dialog editor. Option C allows inline editing - you just have to place edit tags around the individual fields in your repeater rather than around the whole repeater foreach(). For example: <?php foreach($page->my_repeater as $item): ?> <h3><edit <?= $item->id ?>.title><?= $item->title ?></edit></h3> <?php endforeach; ?> You're right that there does seem to be some sort of permissions issue for non-superusers, but rather than change access for the admin template (which non-superusers shouldn't have access to) I suggest you give edit access to your repeater template (select the "Show system templates" option to see repeater templates).

Did you check the front-end editing documentation when investigating your problem? It specifically advises against using option B for Repeaters:

@Juergen, you can create inputfield dependencies based on any arbitrary PHP/API code using the Custom Inputfield Dependencies module, but these are only evaluated when Page Edit is loaded/saved so it may not suit your needs.

@Macrura, I have released a new module PageTable Extra Actions that provides this feature.

PageTableExtraActions A module for ProcessWire CMS/CMF. Allows PageTable items to be published/unpublished and hidden/unhidden directly from the inputfield. Usage Install the PageTableExtraActions module. Use the icons in the "Actions" column of a PageTable field to publish/unpublish or hide/unhide an item. https://modules.processwire.com/modules/page-table-extra-actions/ https://github.com/Toutouwai/PageTableExtraActions/

Not sure - nowhere in the code you posted do you show where $pageArray is defined. What this error means is that $pageArray is a string and not an actual PageArray. Use Tracy to dump $pageArray and find out what is going on with it.

Sounds like you have found a solution that works - nice one. If I understand correctly, your options that may be selected in the Page Reference field are organised into categories according to the hierarchy in the page tree. So for example the hierarchy might be: - colour - red - green - blue - size - small - medium - large But don't you end up with a situation where an editor can ignore your custom button and use PageListSelectMultiple to select the page 'colour' or 'size' instead of one of the actual option pages? To make a more straightforward and foolproof UI you could create a custom inputfield module for the Page Reference field that organises the checkboxes the same as you are doing in the modal front-end page. It's not as difficult as you might think because as you found it's only the value of the hidden input that matters when it comes to submitting the form.

Sure, losing functionality is not good. Elsewhere I proposed a separate button for the cases where you want to add multiple templates. However, in terms of the total amount of convenience for the total number of users, I think the times you want to add fields and other settings immediately after adding a new template much outnumbers the times you want to add multiple empty templates and then end up back at Setup > Templates.

Not sure if this is the cause of the problem, but this line... if($options['useMarkerSettings'] && (count($pageArray) == 1 || !$lat)) { ...does not ensure that $pageArray exists. The if() condition is passed if $options['useMarkerSettings'] and !$lat, regardless of what $pageArray is.

Another approach would be to do a redirect in your template file: $session->redirect('http://www.webshop.com' . $page->url);

I get the feeling this feature is rarely used. I'd like to see it dropped in favour of not being booted back to Setup > Templates after creating a new template, and then having to reopen the settings for the template you just created to add a label, fields, etc. I find that much more a hindrance than I would not being able to create multiple empty templates.