Robin S

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.

For either Version Control or Changelog my thinking was that you would use these just as a way of tracing which pages were deleted from which PageTable fields. You would restore the pages to the PageTable field using the API. The issue with restoring directly from Version Control is that other changes may have been made after the deletion and you wouldn't want to lose those. But I had a better idea anyway which is just to log any deletions from your PageTable field. Here's an example for a single field but you could extend this by foreaching any fields on the current page of type InputfieldPageTable. $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if(!$page->my_pagetable) return; $old_value = $this->pages->getById($page->id, array( 'getFromCache' => false, 'getOne' => true, ))->my_pagetable; $trashed = $old_value->removeItems($page->my_pagetable); if(count($trashed)) { $trashed_ids = $trashed->implode(', ', 'id'); $this->log->save('trashed-pt-pages', "Container page: $page->id | Field: my_pagetable | Trashed: $trashed_ids"); } });

@alexcapes, are you looking for a solution that would allow non-superusers to restore accidentally trashed PageTable pages? Or is it just an occasional mistake that a superuser needs to fix on request? If it's just the latter you could restore the pages from the trash and use Version Control or Changelog to put the PageTable field back how it was before the deletion.

I checked the 'sharpening' setting in $config and that is also overridden by the module config settings. Do you think having module config fields for these default settings is necessary? PW devs are already used to defining the image sizer defaults using $config->imageSizerOptions so would it not be better to stick with that alone? Or do you mean that some devs use both GD and ImageMagick engines in a single PW installation and therefore you need to be able to set different defaults for each?

Limit Table works by hiding elements within the inputfield in Page Edit. You can make a custom solution for Repeater Matrix (or any inputfield) by using your browser tools to find the class/ID of the elements you want to remove, and hiding them with a display:none CSS rule. Add the custom styles selectively to Page Edit via a hook: $wire->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) { $page = $event->object->getPage(); $out = $event->return; // match to the relevant page(s) however suits you if($page->template->name == 'my-template') { $out .= " <style> /* Put your custom CSS here */ </style> "; $event->return = $out; } });

It seems that ImageSizerEngineIMagick ignores the 'quality' setting if one is defined in $config->imageSizerOptions. So if in /site/config.php I have... $config->imageSizerOptions = array_merge($config->imageSizerOptions, ['quality' => 10, 'forceNew' => true]); ...and in my template... echo "<img src='{$my_image->size(300, 300)->url}' alt=''>"; ...then I do not get an image with a quality of 10 (instead it seems to use the default quality defined in the module config). But if I do this then it works... echo "<img src='{$my_image->size(300, 300, ['quality' => 10])->url}' alt=''>"; Weird that this one option would be ignored from $config->imageSizerOptions. @horst or anyone: is this a bug? On the topic of the quality setting, '80' seems too low for the default - I can see some fairly obvious artifacts at that quality. In the blog post that introduced the module, Ryan said: So given the default GD quality is 90, shouldn't the default quality for ImageSizerEngineIMagick be 85 to have consistency across the two sizer engines?

That's a namespace issue. Either add... namespace ProcessWire; ...at the top of your template file, or call the function including the namespace... \ProcessWire\wireRenderFile($filename)

@tpr, these CSS overrides for wide screens are causing a misalignment of the WireTabs in the default admin theme: I'm not sure what the "PrevNextTabs" feature is that requires the override, but if the overrides need to stay could you change to: margin-bottom:calc(-2.6em - 1px);

But it's not a regular include - you are using the wireIncludeFile() function so function scope applies. You can change to a regular include if you don't want limited scope for the included file.