Robin S

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:

@ryan, stuff like this is super-interesting to us aspiring devs and I for one would give my right arm to take a peek at your code and see how an expert approaches these things. It would be a really great learning opportunity. In general, would your client contracts allow you to share snippets of project code with the community? Would you be comfortable doing that? (not expecting you to reveal all your secrets!) Not in any way that would require you to invest time in making things plug-and-play or offering support for them - just dropping some interesting bits as Gists on Github. A possibility?

@rick, when I copied your install method to a test module and corrected the template names to lowercase all the templates and fields were created and assigned without problem. Not sure if the uppercase in the template names would have made a difference - I didn't test that, but probably best to avoid it in any case. Try this for an uninstall method: public function ___uninstall() { // remove fields from fieldgroups and delete $fa = array( 'field1', 'field2', 'field3', 'field4', 'field5', 'field6', 'field7', ); foreach($fa as $f_name) { $f = $this->fields->get($f_name); if(!$f) continue; $fgroups = $f->getFieldgroups(); foreach($fgroups as $fgroup) { $fgroup->remove($f); $fgroup->save(); } $this->fields->delete($f); } // delete templates $ta = array( 'template1', 'template2', ); foreach($ta as $t_name) { $t = $this->templates->get($t_name); if(!$t) continue; $this->templates->delete($t); $this->fieldgroups->delete($t->fieldgroup); // see http://cheatsheet.processwire.com/templates/methods/templates-delete-template/ } } In your testing, if you have been deleting templates via the API and not removing their associated fieldgroups you may have orphaned items left in the "fieldgroups" database table. You'll have to delete those using phpMyAdmin before you can create new templates using the same names. It's surprising that the $fieldgroups API variable is almost completely undocumented. It really should be added to the API reference.

True. To avoid this add... if($this->config->ajax) return; ...at the top of the function. Alternatively you can add a linked stylesheet to the <head> instead of adding the styles directly to the Page Edit source. Something like: $wire->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) { $page = $event->object->getPage(); // match to the relevant page(s) however suits you if($page->template->name == 'my-template') { $this->config->styles->add($this->config->urls->templates . 'admin-custom/my-styles.css'); } }); This is a good way to go if you package the function and stylesheet together into a simple module.

Adding to @Macrura's suggestion: rather than do the preg_replace and str_replace to remove the unwanted doctype, body, etc, you can avoid those by using an options parameter for loadHTML(): $dom->loadHTML($html, LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD);

@tpr, AOS is adding the 'edit template' icon/link to the password inputfield. A bug?

I guess $pages->find() and $users->find() behave differently. You could always use $pages->find() instead... $tsubscribers = wire('pages')->find('template=user'); Be aware that PW does not provide good support for unpublished users. Besides there being no built-in controls in the admin interface for unpublishing a user or saving the user in an unpublished state, there are other gotchas such as the password inputfield being forced to an uncollapsed and required state when editing an unpublished user with no possibility of preventing this via hook (for collapsed state anyway). I requested better support for unpublished users a while back.

Currently the Map Marker inputfield does not support AJAX-loading. I have opened a GitHub issue for this. Until an update is released you can fix the problem by adding the following to InputfieldMapMarker.js: $(document).on('reloaded', '.InputfieldMapMarker', function() { $(this).find('.InputfieldMapMarkerMap').each(function() { var $t = $(this); InputfieldMapMarker.init($t.attr('id'), $t.attr('data-lat'), $t.attr('data-lng'), $t.attr('data-zoom'), $t.attr('data-type')); }); });

@Reid Bramblett, there is a dedicated support thread for this module. First thing to check would be that you have the lastest version of the module installed: v1.1.7 beta. If not, carefully follow the instructions in the first post of the support thread.