Robin S

Cool. But I do think it makes sense for utilities like CodeMirror or Ace to exist as separate inputfield modules so that they can be used elsewhere in Page Edit, other modules, etc, rather that duplicated within every module that uses them. Things like this are not really dependencies (a plain textarea works fine without them) but more a progressive enhancement.

Nice one. How about using InputfieldAceExtended for the configuration textarea if it is installed? if($this->modules->isInstalled('InputfieldAceExtended')) { $f = $this->modules->get('InputfieldAceExtended'); $f->mode = 'ini'; $f->modes = array('ini'); $f->theme = 'twilight'; } else { $f = $this->modules->get('InputfieldTextarea'); } $f->attr('name', 'CKEaddons_toolbar'); //...

One more thing: I think that here and here Aligator should fall back to the selector defined in the defaults rather than an empty string. $selector = isset($options[$level-1]['selector']) ? $options[$level-1]['selector'] : $this->defaultOptions['selector'];

Me again. Is there a way I can set options for all levels of a particular menu without changing the default options? Suppose I have several menus in my site and I have defined some default options for Aligator that suit most of these menus. Now on one of these menus I want to exclude a particular template from all levels in the menu. I don't know how many levels will be in this menu (users may add pages creating additional levels of nesting). So I can use the "selector" setting for this, but do I use this in the default options or the options for that specific menu? It seems like there are catches either way. Default options: works for all levels (good), but affects all the menus in my site (bad). Menu options: limited to this specific menu (good), but I have to repeat the setting over and over some arbitrary number of times to account for all the levels that might exist in the menu (bad). Seems like there should be some way to set default options (all levels) but just for this one menu. Or am I missing something?

I opened a GitHub issue myself: https://github.com/processwire/processwire-issues/issues/383

Client: "What's a filter? Should I add one? Why are there all these dropdowns? What's a num_children? I've forgotten my modified_users_id - can you email it to me? What's a bookmark? I have a bookmark for Google - is it like that? I don't understand what I do on the columns tab. My brain hurts. Why did you make this so confusing? etc, etc, etc" But seriously, it's just a permission so you have the option to show Lister to a role or not show it to a role. It's just to give flexibility.

Not sure why you are using an Options field for this. I think you want an integer field named "number_of_saves" or whatever. Then you increment the number with each save originating from the front-end.

Hi @abdus, Can you say more about this? Does this... $foo = $pages->find("template=foo"); foreach($foo as $foo_item) { //... ...use more memory than... foreach($pages->find("template=foo") as $foo_item) { //... ...? I thought these would be same in terms of memory usage, or is memory able to be "released" later somehow if you are not assigning to a variable?

Thanks for the suggestions for including "Home" - I had been playing around with adding a "show_root" option to Aligator but your suggestions are simpler and better. I made a few other changes in a fork of Aligator that I'll pass on for consideration. 1. I think there is a typo here - should be... if($return["wrapperClose"]) { 2. I changed the early returns so that an empty string is returned, to be consistent with the @return tag in the function DocBlock. 3. I added a new argument that is supplied to the callback function - a $props array of some menu-related properties of the current $item. The reason being that these properties are commonly needed to work out the menu markup, and they are already determined within the Aligator render() function - so it makes sense to pass 'is_parent', 'is_current' and 'num_children' as an argument rather than have to determine them again separately in the callback function. I also included 'is_first' and 'is_last' in the $props array because it is much more efficient to determine this within render() from the $key in the foreach (just like is done in MarkupSimpleNavigation) than in the callback as per my post above. But now that I think about it I don't know that these properties are that useful after all - probably anything you would use them for could be just as easily achieved in CSS or JS with :first-child and :last-child. 4. Lastly, because of the $props argument I override 'is_parent' and 'num_children' in the case of the Home page being rendered. That's because despite the way PW treats Home as the root parent of all pages (there are probably good reasons for this), I think most website users think of the Home page as a sibling of the top-level pages rather than a parent of them. The commit with my changes is here if you are interested.

Wow, super update this week! The SCSS compilation feature in ProCache sounds great. Currently I have a roll-my-own solution using scssphp - does the new ProCache feature use scssphp or something different? The front-end users module is awesome news - it's one of those few missing pieces that PW has been really needing. Beginners especially will benefit from this, and because of the security considerations that come with a login system it's great to have a solution from PW's creator. I was expecting that such a module would be a "Pro" release, so big thanks for making this a free module! Can't wait to try it.

That error from the Repeater module looks like the same thing I raised a GitHub issue for recently, so there's a good chance it relates to PW's caching of module data rather than Recurme specifically. Ryan has pushed a fix for the issue to the dev branch.

There's nothing invalid about the original page name in your gif. Adding the $beautify argument to $sanitizer->pageName() will give a result that is closer to the JS replacement that happens in the admin interface. But I take your point that it would be useful to have a sanitizer option that is an exact match for the JS replacement.

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.