Robin S

Welcome @Cabcom, Sure it is possible, but not a simple task. You'd be looking at something like the following: Create elements (divs or whatever) in the front-end that represent your repeater items (probably using repeater item page ID as an identifier). Use some Javascript on the elements that supports drag-and-drop sorting - I'm sure there are a number of off-the-shelf solutions for this. When a submit button is clicked, submit an array of the the repeater item IDs in the current sort order to a ProcessWire page (using a form or AJAX). In the template for that page, get the submitted array and apply the sorting to the repeater field using the API. It might be easier to remove all items from the field and then add the items back in the array order than to try and adjust the sorting of the items already in the field. If you are up for the challenge I'm sure you'll find help here in the forums if you get stuck on a step.

I tested and cannot reproduce. For published pages, editing and saving a page updates the modified timestamp but not the published timestamp. But for news pages I think it is more typical to add a datetime field to the template to serve as the posting date, so the user can change the date to suit. For instance, to set a future posting date and then in your news selector you exclude pages with posting date greater than today.

@tpr, there is an issue with the "edit field" helper link shown in Page Edit for fieldsets. Instead of linking to the the settings of the fieldset itself it links to the settings of the first child field of the fieldset.

Probably a question best answered by Ryan in the pro support board, but this worked for me... // Name of repeater matrix field $matrix_field_name = 'test_matrix'; // Name of matrix type you want to add field to $matrix_type_name = 'type_1'; // Name of field you want to add to matrix type $add_field_name = 'images'; // Get field objects $matrix_field = $fields->get($matrix_field_name); $add_field = $fields->get($add_field_name); // Add field to repeater matrix fieldgroup $matrix_template = $templates->get("repeater_$matrix_field_name"); $matrix_fieldgroup = $matrix_template->fieldgroup; $matrix_fieldgroup->add($add_field); $matrix_fieldgroup->save(); // Associate field with matrix type $matrix_types = $matrix_field->type->getMatrixTypes($matrix_field); $matrix_type_integer = $matrix_types[$matrix_type_name]; $property = "matrix{$matrix_type_integer}_fields"; $field_ids_in_type = $matrix_field->$property; $field_ids_in_type[] = $add_field->id; $matrix_field->$property = $field_ids_in_type; $matrix_field->save();

See the "https" property of the Template class: https://processwire.com/api/ref/template/ $t = $templates->get("name=admin"); $t->https = 0; $t->save();

@rst, when you get 403 or 404 errors after submitting a form then it is usually mod_security that is to blame, as suggested above. You'll need to get it disabled one way or another. If you are on a cPanel host you can sometimes disable it there... ...otherwise you need to put in a support request to your host and ask for it to be disabled.

Hi @tpr, I've been working on a module that adds an icon to file items in a File field and checking to make sure it plays nicely with the "noFilenameTruncate" option in AOS. So I've been looking closely at the layout and have a suggestion for fine-tuning the noFilenameTruncate styles. Here is the default appearance of a File field, without AOS noFilenameTruncate activated: And here is the appearance when noFilenameTruncate is activated: And what I'd like to suggest is... Reduce the padding of the header to compensate for the extra line-height you added. The float:left you added to the file icon shifts it up a bit from the default, so compensate for that with a some extra top offset. Put the delete icon back over on the right by positioning it absolutely. It's better over there if you have several files to delete because you don't have to go hunting for it. The result... And the modified SCSS for that: html.noFilenameTruncate { p.InputfieldFileInfo.InputfieldItemHeader { padding: 6px 34px 6px 25px; position: relative; } i.fa-file-image-o, .InputfieldFileInfo i { left: -21px !important; top: 3px; float: left; } a.InputfieldFileName { line-height: 1.33; margin-left: -22px; word-wrap: break-word; } label.InputfieldFileDelete { position: absolute; top: 8px; right: 8px; } } What do you think?

$cc_recipient[0] is the first item in the array - if you dump that item, is it a valid email address? Also, you say WireMail but as far as I know there is no CC method in the WireMail base class. Maybe you are using some module that extends WireMail?

@waheed, Repeater items are pages so what you want is a Page Reference field. Set the selectable pages to the value of the Repeater field (which is a PageArray).

There are long-standing issues with the $user page having output formatting off by default - there are a number of forum topics where it has come up. I'm not sure if it's deliberate or if output formatting is off consistently for $user, but you could use $user->getFormatted('date') to be sure. Related topics:

@cjx2240, I made a new module...

See this issue: https://github.com/processwire/processwire-issues/issues/267 The example hook has been updated on the dev branch. $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'mypages') { $event->return = $event->pages->find('your selector here'); } });

Restrict Repeater Matrix Allows restrictions and limits to be placed on Repeater Matrix fields. Requires ProcessWire >= v3.0.0 and FieldtypeRepeaterMatrix >= v0.0.5. For any matrix type in a Repeater Matrix field you have the option to: Disable settings for items (cannot change matrix type) Prevent drag-sorting of items Prevent cloning of items Prevent toggling of the published state of items Prevent trashing of items Limit the number of items that may be added to the inputfield. When the limit is reached the "Add new" button for the matrix type will be removed and the matrix type will not be available for selection in the "Type" dropdown of other matrix items. Hide the clone button when the limit for a matrix type has been reached. Note that in PW >= 3.0.187 this also means that the copy/paste feature will become unavailable for the matrix type. Please note that restrictions and limits are applied with CSS/JS so should not be considered tamper-proof. Usage Install the Restrict Repeater Matrix module. For each matrix type created in the Repeater Matrix field settings, a "Restrictions" fieldset is added at the bottom of the matrix type settings: For newly added matrix types, the settings must be saved first in order for the Restrictions fieldset to appear. Set restrictions for each matrix type as needed. A limit of zero means that no items of that matrix type may be added to the inputfield. Setting restrictions via a hook Besides setting restrictions in the field settings, you can also apply or modify restrictions by hooking RestrictRepeaterMatrix::checkRestrictions. This allows for more focused restrictions, for example, applying restrictions depending on the template of the page being edited or depending on the role of the user. The checkRestrictions() method receives the following arguments: $field This Repeater Matrix field $inputfield This Repeater Matrix inputfield $matrix_types An array of matrix types for this field. Each key is the matrix type name and the value is the matrix type integer. $page The page that is open in ProcessPageEdit The method returns a multi-dimensional array of matrix types and restrictions for each of those types. An example of a returned array: Example hooks Prevent the matrix type "images_block" from being added to "my_matrix_field" in a page with the "basic-page" template: $wire->addHookAfter('RestrictRepeaterMatrix::checkRestrictions', function(HookEvent $event) { $field = $event->arguments('field'); $page = $event->arguments('page'); $type_restrictions = $event->return; if($field->name === 'my_matrix_field' && $page->template->name === 'basic-page') { $type_restrictions['images_block']['limit'] = 0; } $event->return = $type_restrictions; }); Prevent non-superusers from trashing any Repeater Matrix items in "my_matrix_field": $wire->addHookAfter('RestrictRepeaterMatrix::checkRestrictions', function(HookEvent $event) { $field = $event->arguments('field'); $type_restrictions = $event->return; if($field->name === 'my_matrix_field' && !$this->user->isSuperuser()) { foreach($type_restrictions as $key => $value) { $type_restrictions[$key]['notrash'] = true; } } $event->return = $type_restrictions; }); http://modules.processwire.com/modules/restrict-repeater-matrix/ https://github.com/Toutouwai/RestrictRepeaterMatrix

@cstevensjr, wow, I did not know that unpublishing a page had the effect that the page and its children are hidden to site editors. Great tip!

Yeah, when I first started working with pages simply as options for a Page Reference field I thought that their presence in the page tree might be confusing for editors, but nobody has ever mentioned it so I don't worry about it now. Another thing that probably works but that I haven't tried is storing such pages under the Admin branch of the tree. Does anyone do this and does it work okay?

Thanks for the replies. I remembered a downside of the Options fieldtype and that is awkwardness of adding selectable options to the field via the API: I think I will stick with Page Reference fields for the most part.

@Roych, if a second argument is given to date() it must be a timestamp. So you need the unformatted value of the date field: <?php if (date('d-m-Y') == date('d-m-Y', $single->getUnformatted('Start_date'))): ?> <div class='Danes-text'>TODAY!</div> <?php endif; ?>

In a situation where you need some options for an inputfield and it's unlikely that any subfields will ever need to be added to those options, is there any reason to prefer a Page Reference field over an Options field or vice versa? I'm not concerned about the setup time for either (probably Options is a little faster but there's not a lot in it) - just if one is perhaps more performant than the other or there is some catch with one of them that isn't obvious at first. I've always used Page Reference fields so far.

@JimSee, that error can sometimes be caused by a weird invisible whitespace character in your code, particularly if you copy/pasted it from somewhere. Try deleting this part... $content .= $page->comments->render(array( 'headline' => '<h2>Read Comments</h2>', )); ...and then typing it out again from scratch.

Is this a known bug that has been reported at GitHub? I couldn't find any report for it so have opened a new issue here. @JimSee, until this is fixed in the core you can work around the date format issue by supplying a date format as part of the $options array when you render the comments list, e.g. echo $page->comments->render(array( 'headline' => '<h2>Read Comments</h2>', 'dateFormat' => 'm/d/y g:ia', )); The website is rendered as a link using the commenter's name as the link text:

Hi Margie, Those last two questions in particular sound like they could only be answered by Ryan and I'm not sure how closely he follows these boards. You might be better to contact him via the Contact page.

No bugs that I know of. I'm using it on a few live sites. Should be fine.

I'm having an issue when trying to uninstall the Recurme module (v1.0.1) - after checking "Uninstall" and submitting I get a fatal error from PHP timeout (60 seconds). The issue occurs when trying to uninstall from any of the Recurme sub-modules.

Here is a recent example of how you can parse HTML content when a page is saved: Via the field settings: Setup > Fields > [your CKEditor field] > Input > CKEditor Settings But I'm still not convinced it is necessary to add this class. Not sure if you understood what I was getting at in my last post, but if for instance you are wanting to add this class because you are using the Bootstrap framework you can simply add a line of CSS to apply the same styling as 'img-responsive'. .cke-content img { max-width:100%; height:auto; display:block; }

I have witnessed that myself from time to time, but have never worried about it because it didn't seem to affect anything. If you can reproduce it on a clean installation (to rule out any module issues) then might be worth raising a GitHub issue.