Robin S

Superb website. It should be included in the featured sites if it isn't already. Perhaps your filter queries are not optimal. Feel free to post the filter code if you would like any feedback on this.

Hi @Soma, I finally got around to trying this module - it's really powerful, I love it! A couple of questions: 1. Is there a way to include the Home page in a navigation generated by this module? Something like the 'show_root' option in MarkupSimpleNavigation? 2. If I want to add 'first' and 'last' classes to my nav items (like the 'firstlast' option in MarkupSimpleNavigation) is the following a good way or can you see a more efficient way? In my callback function I add to the $class variable like this... $class .= $item == $item->siblings()->first() ? ' first' : ''; $class .= $item == $item->siblings()->last() ? ' last' : ''; TIA.

For anyone not following the issues repo: Ryan has committed a fix for this issue to the dev branch.

Ryan committed a change back in May in response to this issue but it hasn't been merged to the master branch yet.

Thanks for the suggestion, but site profiles created by ProcessExportProfile already do not include any content in the caches table (the table is created but nothing is inserted into it).

Thanks for the reply - you're definitely on the right track there. Your suggestion solves the issue for PW 3.0.62, but when installing PW 3.0.75 I still get the error below: I'm guessing that might be due to this part of FieldtypeRepeater.module firing as soon as PW is bootstrapped, before the module cache has had the chance to clear. Can you see a way to work around that? Edit: this edit to FieldtypeRepeater does the trick... if(!$field->type || $field->type->className() != $className) continue; I have created a GitHub issue for this.

Update: seems like the issue is not related to that particular custom Fieldtype module - it just happened that it was the only non-core Fieldtype module installed in my profile. I added FieldtypeMapMarker to my site profile and got this when installing PW 3.0.62... So I'm thinking it's a bug with either the PW installer or ProcessExportProfile, but I'm keen to hear anyone's thoughts on this.

I have an issue that has been a mild annoyance for a while but has become more serious now due to a core change. The issue occurs at the end of the PW installation process using a custom site profile that I generated using ProcessExportProfile, and relates to a custom Fieldtype module not being "known" to PW immediately after installation. The error I used to get is this... ...and it was of no real consequence. I just ignore the message and on the next page load the message does not reappear (I used to do a Modules > Refresh but after more testing today it seems this isn't necessary - just reloading the page is enough to resolve the message). The issue relates to this section of code and seems to indicate that FieldtypeSelectImage is not included in $fieldtypes immediately after installation. But as soon as I login and check with Tracy I can see FieldtypeSelectImage is included as expected: Due to recent changes to FieldtypeRepeater.module I now get a more serious problem at the end of installation that prevents me from completing the installation, and install.php is left behind... Again due to the FieldtypeSelectImage fieldtype not being present in $fieldtypes. Now FieldtypeSelectImage is a custom module I created, and it was the first PW module I ever made so it wouldn't surprise me if there was some mistake in it. But there are other similar issues reported in the forums so I think it might be a more general issue that isn't specific to this particular module. https://processwire.com/talk/topic/574-site-copied-to-development-server-fieldtype-does-not-exist/ https://processwire.com/talk/topic/4067-site-doesnt-work-after-hosting-migration/ https://processwire.com/talk/topic/13781-problems-after-installing-remote-copy-to-local/ The agreement seems to be that the issue relates to the module cache, but what can I do to prevent the issue occurring during installation? The cache file that Ryan mentions in his reply to one of the threads above does not exist in my case. Is there some change I need to make to FieldtypeSelectImage so that PW can recognise it during the PW install process? The module code:

@thetuningspoon, sounds like a bug then, as if the dependency evaluation does not account for the situation where a field may be excluded from ProcessProfile. Your code changes look like a improvement - maybe log an issue and suggested fix on GitHub?

Sure, be my guest.

Are you using the role name in the dependency selector string? If so you need to use the role ID instead.

You can do this with a hook to Pages:added() in /site/ready.php $pages->addHookAfter('added', function(HookEvent $event) { $page = $event->arguments(0); if($page->template->name !== 'project') return; // Only for this template // Define your default labels and values $defaults = [ 'Size' => '', 'Year' => '2017', 'Location' => 'New Zealand', 'Status' => '', ]; // Add default items to repeater field foreach($defaults as $key => $value) { $item = $page->meta_fields->getNew(); // Populate subfields $item->field_1 = $key; $item->field_2 = $value; $item->save(); $page->meta_fields->add($item); $page->save(); } });

Good idea.

PageListTrash Allows non-superusers to trash pages directly from Page List (if they have page-delete permission for that page). Not much to say really - the module adds a "Trash" option to the extra actions for pages in Page List. It looks and works just like the Trash action available to superusers. https://github.com/Toutouwai/PageListTrash/ Up to you whether you think non-superusers should be trusted with simpler trashing. For most cases I like the default behaviour where editors have to jump through some more hoops - I want them to think carefully about what they are doing. But if an editor needs to trash several pages then this module might reduce frustration. @tpr, by now you can probably predict what I'm going to say... ...something to merge into AdminOnSteroids?

The thing that can potentially allow Table to scale up to a very large number of rows is the ability to paginate the rows, both in output and in the admin interface. Pagination is not enabled by default but is an option. You could probably have 150 rows in an AJAX-loading repeater without a technical issue, but for both Table and Repeater you could have a bit of a usability issue with that number of rows. Imagine dragging a row from bottom to top for instance. And I don't know if that's even possible with a paginated Table interface (how do you drag from the last page to the first?). But these problems seem like they just go with the territory of what you are needing to do and the number of items you need to support. If you think you will work on more PW projects I'd say it's definitely worth purchasing ProFields. It's fantastic value for money, just for Table and Repeater Matrix alone.

Yes, that's what it boils down to basically. There are several reasons for this depending on the fieldtype to be edited, but in the case of a repeater PW has no idea what you are doing in terms of displaying your repeater output on the frontend - it gives you total flexibility there. So PW cannot really provide an inline frontend interface for drag-sorting repeater items for instance, because there is no guarantee you are even presenting all of your repeater subfields contiguously inside a single containing div. So I think you'll need to resign yourself to modal editing unless you are up for some serious custom frontend interface work. I'm curious to see the existing interface your client is using - it sounds quite fancy. Maybe you could post a video? (LICEcap is useful) Repeaters scale to a medium level fine so long as you use the AJAX-loading setting. I haven't tried Table with frontend editing but I think any fieldtype becomes editable via a modal.

I'm a bit confused about exactly what you want to do, but it sounds like the default frontend edit behaviour (where non-superusers edit a repeater field via a modal) is exactly what you need. When your editor goes to edit anything in the repeater on the frontend they get a modal where they can edit any of the fields within a repeater item, add new repeater items, delete them, drag them, etc. In your template file you surround the entire repeater foreach() with edit tags (editing method C or D) - have you tried this yet?

I haven't followed this discussion closely so sorry if I'm missing the point here, but I believe you can override the append/prepend files directly when you render a page with $page->render(). echo $p->render( ['prependFile' => null, 'appendFile' => null] );

@joshuag, I think I have fixed the uninstallation issue. I found a few other issues in the module code too - I will PM you with the details.

Just something I was trying out recently that might be useful to someone... With the following hook added to /site/ready.php you can adjust the CKEditor toolbar that a particular role gets for a particular field. Use the name of your CKEditor field in the hook condition. $this->addHookBefore('Field(name=my_ckeditor_field)::getInputfield', function(HookEvent $event) { $field = $event->object; // Define toolbar for a particular role if($this->user->hasRole('editor')) $field->toolbar = 'Format, Bold, Italic, -, NumberedList, BulletedList, Outdent, Indent'; }); Or what I find useful on some sites is adding extra toolbar buttons for superuser only that you don't trust editors to use. $this->addHookBefore('Field(name=my_ckeditor_field)::getInputfield', function(HookEvent $event) { $field = $event->object; // Add extra buttons for superuser only if($this->user->isSuperuser()) $field->toolbar .= ', Table, TextColor'; }); You could use the same technique to selectively define other CKEditor settings such as 'stylesSet', 'customOptions', 'extraPlugins', etc.

Superusers may edit individual repeater items inline (not in a modal) but non-superusers may not. There's an open issue regarding it (with a possible workaround you can use at your own risk) but based on Ryan's comment here I think he is not inclined to view this as a bug to be fixed.

No solid solution but just wanted to say that you're not alone - I get this from time to time too. Sometimes I can solve it by rebooting all my devices.

FYI, a while ago a wrote a little tutorial demonstrating how an array_chunk method can be added to WireArray:

Hi and welcome @dscONE! Yes, I do think the behaviour you have discovered is unexpected. Just to reiterate in a simplified way what I think you are saying.... The expected behaviour is that for any selector, the combined results of $pagearray->find($some_selector) and $pagearray->not($some_selector) should equal the entire PageArray. But this is not the case, as can be demonstrated with a PageArray containing three pages titled "red car", "blue car", "green truck"... $matches = $pagearray->find("title~=car"); // "red car", "blue car" $not_matches = $pagearray->not("title~=car"); // "green truck" // So far, so good $matches = $pagearray->find("title~=car, !title~=red"); // "blue car" $not_matches = $pagearray->not("title~=car, !title~=red"); // expected "red car", "green truck" but got unexpected empty PageArray Would you please report this issue over at the PW issues GitHub repo? https://github.com/processwire/processwire-issues/issues

I'm guessing he is talking about the profile edit interface (ProcessProfile). There are a couple of places where the module assumes/requires ProcessPageEdit.