Jump to content

Robin S

Members
 View Profile  See their activity

  • Posts

    4,928

  • Joined

  • Days Won

    321

 Content Type 

Everything posted by Robin S

  1. Robin S
    @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?
  2. Robin S
    @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.
  3. Robin S
    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.
  4. Robin S
    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);
  5. Robin S
    @tpr, AOS is adding the 'edit template' icon/link to the password inputfield. A bug?
  6. Robin S
    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.
  7. Robin S
    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')); }); });
  8. Robin S
    @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.
  9. Robin S
    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"); } });
  10. Robin S
    @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.
  11. Robin S
    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?
  12. Robin S
    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; } });
  13. Robin S
    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?
  14. Robin S
    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)
  15. Robin S
    @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);
  16. Robin S
    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.
  17. Robin S
    It would be possible to get the relationship at the time a page is trashed - for instance, with a PageTable field you could hook InputfieldPageTable::processInput() and get the pages about to be trashed. As for simple it depends on what you're comfortable with. To store the information in a self-contained way your module would need to create and use its own database table. There are existing modules you could look at as an example of how to do this, e.g. Template Access by Parents
  18. Robin S
    Right you are. When you open a request there is a dropdown to select which Pro module you are wanting help with. So all good I guess. Just funny that there's no mention of this section in the Pro modules information, rather the private sub-forums are mentioned as where support is provided. I have a number of Pro modules and I don't recall ever hearing about it. So probably LK is right and it just comes as part of the store package.
  19. Robin S
    By "Support" section I mean this: I've never even looked in this section before, and I haven't heard of anyone using it. But based on a comment today maybe some new users do go there looking for help: Is this section used by the community and monitored by anyone? If not perhaps it should be removed. Thoughts?
  20. Robin S
    @tpr, just a heads up about another issue over on GitHub along with a possible fix.
  21. Robin S
    @tpr, I've been having a look at the images-in-repeater issue for non-superusers (I discovered this one a while back but forgot to report it here, sorry ). ----- Edit: I did report it over in the Github repo. Edit 2: looking at some PM history it looks like a solution (same intent but different implementation to that proposed below) was found but never merged into the repo? ----- As you found, the $this->editedPage property is the source of the issue. Seeing as the things this property is used for within the module either don't work within repeaters (e.g. field edit links) or aren't needed for repeater pages (e.g. breadcrumb features) I think $this->editedPage should never be set to a repeater page. But it's much easier to exclude repeater pages in ready() because in init() it is not yet known which class a page is an instance of. So could $this->editedPage be set in ready() instead? This is what I did in my testing and it seems to work okay: public function init() { // removed code that sets $this->edited page // populate self::$configData self::$configData = $this->modules->getModuleConfigData($this); // ... // a bit further down we need to change $configData[$subModule] to self::$configData[$subModule] public function ready() { // set $this->editedPage // excluded repeater pages, minor refactoring $this->editedPage = false; $editedPageId = $this->sanitizer->int($this->config->input->get->id); $editedPage = $this->pages->get($editedPageId); if( $editedPage->id && !($editedPage instanceof RepeaterPage) ) $this->editedPage = $editedPage; self::$configData = $this->modifyConfigData( $this->modules->getModuleConfigData($this), $this->editedPage ); // ...
  22. Robin S
    I think you want: if($config->ajax) {} $config->ajax
  23. Robin S
    Works great, thanks!
  24. Robin S
    I can confirm that sorting by repeater count does not work. Seems like a bug to me, considering that it's possible to sort by Page Reference count and PageTable count and those are quite similar fieldtypes. @Tom., maybe open an issue on GitHub?
  25. Robin S
    In another thread Ryan said: Might be something in the discussion that helps:
×
×
  • Create New...