Robin S

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.

Discussed in these threads:

$page->files means "the value of a field on the page named files" - it isn't a special method that somehow gets any files you have added to the page. You have named your files field "document_Files" so you get its value with $page->document_Files. If you have no field named "files" then trying to get a field value by that name will return null.

Hi Nancy Reagan fan, There are a number of different ways you could do this, but if you want the class added to all images inserted via CKEditor then the simplest is to do it client-side with jQuery. 1. In your template file(s), wrap the output of your CKEditor field(s) with a div so you can identify them: echo "<div class='cke-content'>$page->body</div>"; 2. In a Javascript file: $(function() { $('.cke-content img').addClass('img-responsive'); }); But consider if you really need to add this class or not. If you wrap your CKEditor content as in step 1 then you can target the images in your CSS/JS with ".cke-content img" without needing to add a class to the images themselves.

@artaylor, I tested this and PW does not interfere with htpasswd protection of a folder in the site root. Your folder structure should look like this: /protected-folder/ protected-file.txt .htaccess .htpasswd /site/ /wire/ ...etc This works for protecting 'protected-file.txt' (or any file in this folder). But you cannot get the directory listing for 'protected-folder' unless you explicitly enable indexes in /protected-folder/.htaccess by adding this: Options +Indexes

It does NOT add the page to my "galerias" pagetype field. It works for me. Double-check your page IDs, field name, and settings of your Page Reference field (allows multiple pages, 'selectable pages' settings allow the page you are trying to add).

Good idea, thanks.

Without declaring the ProcessWire namespace at the top of a module file I don't get the benefit of code completion and warnings in my IDE (or rather I get a bunch of false-positive warnings without a namespace declared). So I'd like to declare it, but if I understand right this will make the module incompatible with PW 2.x. It would be great to be able to conditionally declare the namespace according to the PW version but that's not possible unfortunately. I suppose I could declare the namespace and comment it out just before pushing to GitHub, but it would be easy to forget. Any tips? Does anyone know if there's a way to indicate the namespace in a DocBlock comment so PhpStorm picks it up but it isn't an actual namespace declaration?

@Macrura, your Micro Contexts idea is clever. The approach you are taking here (effectively a single template where fields may be shown/hidden and labels/descriptions changed depending on context) is in fact exactly what is done in Repeater Matrix. Every matrix item (page) actually has the same fields, but the field visibility and labels etc are controlled by the matrix type context. So that got me thinking that all that is needed to do something similar with Repeater Matrix is to add some control that allows the user to change the matrix type of an existing Repeater Matrix item. The advantages over the Micro Contexts approach are: You don't have multiple templates that must be kept in sync if new fields are added - if you add a new field to any given matrix type it is added to the single Repeater Matrix field template. You can do all your field overrides (visibility, width, label, description, notes) from a single screen (the Repeater Matrix field settings). So as a result it's quicker to set up and easier to maintain. I have put in a request to Ryan to add such a control, but I had a play around and managed to get something working with a couple of hooks. To use this... Create a new text field named 'block_type' (best to create a dedicated field for the purpose). Set the field visibility to 'Closed' (to keep it discreet). In your Repeater Matrix field settings, add the block_type field as the first field in each matrix type. Add the hooks below to /site/ready.php... // Change the block_type inputfield to a matrix type select $wire->addHookAfter('InputfieldText::render', function(HookEvent $event) { $inputfield = $event->object; $field = $inputfield->hasField; if(!$field || $field->name !== 'block_type') return; if($inputfield->name === 'block_type') return; // in case field is not being rendered inside repeater inputfield $rpage_id = str_replace('block_type_repeater', '', $inputfield->name); $rpage = $this->pages->get($rpage_id); if(!$rpage->id) return; // just in case $matrix_field_name = substr($rpage->template->name, 9); $matrix_field = $this->fields->get($matrix_field_name); $raw_matrix_types = $matrix_field->type->getMatrixTypes($matrix_field); $matrix_types = []; foreach($raw_matrix_types as $key => $value) { $label = $matrix_field->get("matrix{$value}_label"); $matrix_types[$value] = $label ?: $key; } $if = $this->modules->get('InputfieldSelect'); $if->name = $inputfield->name; $if->label = $inputfield->label; $if->required = true; foreach($matrix_types as $key => $value) { $if->addOption($key, $value); } $if->value = $rpage->repeater_matrix_type; $event->return = $if->render(); }); // Change the matrix type on saveReady $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if(!$page instanceof RepeaterMatrixPage || $page->block_type === null) return; if($page->isChanged('block_type')) $page->setMatrixType($page->block_type); }); If you wanted to remove certain Repeater Matrix inputfield controls then you would use a hook/module as discussed in earlier posts in this thread.

These topics may be useful: