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
    You can achieve this using the "Custom PHP code" option for the Page Reference fields, but your site editors will need to save the page after making a selection in each Page Reference field in order for the selected items to be removed from the options of the other fields. Example hook in /site/ready.php: $wire->addHookAfter('InputfieldPage::getSelectablePages', function(Hookevent $event) { $page = $event->arguments(0); // The page being edited if($event->object->hasField == 'colours') { // Exclude options selected in field colours_2 $event->return = $event->pages->find("template=colour, id!={$page->colours_2}"); } if($event->object->hasField == 'colours_2') { // Exclude options selected in field colours $event->return = $event->pages->find("template=colour, id!={$page->colours}"); } }); Result in Page Edit:
  2. Robin S
    This part doesn't look quite right for a couple of reasons... Firstly, the value of a repeater field is a PageArray even if the field is empty, so is_null() is never going to return true regardless of whether there are any repeater items. Secondly, if film_days is a repeater then you have to loop over its value - you can't get a field value of a child repeater item with $p->film_days->film_times So for that section of code I think you want something like: // remove all the old data (verbose) if($p->film_days->count()) { foreach($p->film_days as $film_day) { if($film_day->film_times->count()) { $film_day->of(false); $film_day->film_times->removeAll(); $film_day->save(); } } $p->film_days->removeAll(); $p->save(); } ...and to shorten it I don't think you need to worry about removing film times in film days you are about to also remove - just remove the film days and the film times will be gone too: // remove all the old data if($p->film_days->count()) { $p->film_days->removeAll(); $p->save(); }
  3. Robin S
    Thanks @eelkenet, fixed in v0.1.4.
  4. Robin S
    @breezer, like I said, your issue is not related to this module and you can confirm this by uninstalling TemplateFieldWidths. But your admin layout looks non-standard - compare with my screenshot above which does not have the grey background or space between inputfields. Maybe this is caused by some non-default option in AdminThemeUikit or you have interference from some non-core CSS somewhere.
  5. Robin S
    Are we talking about layout issues in the "Field widths" field that TemplateFieldWidths adds to the Edit Template screen... ...or layout issues when you are editing a page/profile? Because TemplateFieldWidths doesn't have anything to do with the latter - the module just adds a quicker way to define field widths. You can check by uninstalling TemplateFieldWidths and seeing if you still have layout issues when editing a page/profile. If it's the latter problem you could ask a question one of the main support forums, but also check this loooong GitHub issue about column widths in AdminThemeUikit: https://github.com/processwire/processwire-issues/issues/480 Personally I recommend the following config option: Modules > Core > AdminThemeUikit > Layout + interface > Inputfield column widths > Percentage-based widths
  6. Robin S
    Sounds like a CSS box-sizing issue. Are you using an unmodified core admin theme? All three core admin themes apply box-sizing: border-box to all elements so I'm puzzled why that wouldn't be working in your case. Maybe you can use your browser dev tools to investigate?
  7. Robin S
    An updated version supporting both GitHub and GitLab: (not sure if the GitHub authentication works because I don't have the paid account needed in order to create a private repo) Sure, that's fine.
  8. Robin S
    For those interested, here is a proof-of-concept Process module for parsing a module version number from a GitLab repo, public or private (if you have an access token). For demonstration there is a form for entering the module info and displaying the retrieved version, but for real usage you would send the module info to the Process page by POST and get the version number back in an AJAX response. Form... ...and with version number returned...
  9. Robin S
    VisBug looks nice indeed:
  10. Robin S
    That's a good point, thanks. Have changed to left alignment in v0.1.5. Not sure I want to make this change as if the show original field width config option is enabled it makes the label a bit disconnected from the input, and for longer field names in narrower columns (esp. on narrower screens) it increases the likelihood of the field name not fitting within the column width. Having the field label break to underneath the input wouldn't be great. So I'm thinking the costs aren't worth the benefit of slightly more efficient use of vertical space. But if others would prefer everything on a single line I'm willing to reconsider. Yeah, not sure I'm up for tackling that, but if you're tinkering around some time and find a solution that would be cool. ?
  11. Robin S
    Good solution, but a couple of things: 1. It would be sensible to add a few restrictions about what page can be retrieved by the $pages->get(). The page ID is user input so potentially any page ID could be inserted into the URL allowing a user to see pages that they should not have access to: unpublished repeater pages, or indeed any page including admin pages could be rendered (although PW has extra checks here that would probably prevent anything sensitive from being disclosed). Something like this would be safer: $id = $sanitizer->int($input->urlSegment1); $match = $pages->get("id=$id, template=repeater_your_repeater, status!=unpublished"); 2. Calling $match->render() will only produce output if a template file exists for the repeater, which is normally not the case. It's possible to add a repeater template file but it might be easier to echo individual field values from $match.
  12. Robin S
    Thanks, fixed in the latest version.
  13. Robin S
    v0.1.3 adds a tabbed interface for fieldset tabs, and there is a new config option to show the original field width alongside the template context field width.
  14. Robin S
    My objective is to avoid needing to mouse to and click anything in the "Field widths" field. Right now I can use the tab key to move through all the fields, but if some fields are inside a hidden tab content div then I suspect it may be quite difficult to keep this functionality. If it were just a matter of showing the tab content with the focused field that would be fairly simple, but I suspect the browser will refuse to focus an input inside a hidden div (I haven't checked yet). In the PageEdit/WireTab example, PW will not move focus from the last field in Tab A to the first field of Tab B using the tab key.
  15. Robin S
    Personally I would find that more distracting than useful, but will look at adding it as a configurable option. I can see why this would be good, but I wouldn't want to lose the ability to use the tab key to move through all fields in the template. Will do some experimenting and see if it's possible to keep the tab key navigation in a tabbed interface - I have a feeling that hidden inputs may not be focusable with tab.
  16. Robin S
    I think this might be one of those cases where a little debugging saves a lot of head-scratching. Try dumping the value you are trying to match: Now it's obvious what the cause of the issue is. The title field has the entity encoder textformatter applied (like all text fields should), so the formatted value that is prepared for display on the front-end is different than the unformatted value that is saved in the database and that you are searching against with $pages->find().
  17. Robin S
    Looks cool! Does your script parse out the version number from the getModuleInfo() method / ModuleName.info.php file / ModuleName.info.json file? If so, would you be willing to share the code from that part? I have an idea in mind for how to do this but it would be no surprise if your idea was better. ?
  18. Robin S
    @matjazp, thanks for the suggestions. Yes, done in v0.1.2 Sorry, no, if I'm wanting numbers to sum to exactly 100 then I much prefer a number input than a slider. Just tab from field to field and it's very quick. Great idea, done in v0.1.2
  19. Robin S
    This might be a question only @ryan can answer, or maybe someone know if Ryan has ever shared the code used in the PW Modules Directory... I want to make a module similar to ProcessWireUpgrade except for private modules that are not in the modules directory. I haven't decided yet exactly how this will work (get each module info on demand direct from the repo or set up a private modules directory that gets several module's info on a lazycron), but part of it will need to be parsing the version number from the getModuleInfo() code in the module repo. I can probably muddle through this but rather than reinvent the wheel, is it possible to see how the PW Modules Directory does it?
  20. Robin S
    emplate Field Widths Adds a "Field widths" field to Edit Template that allows you to quickly set the widths of inputfields in the template. Since v0.2.0 the module also adds a similar field to the settings of Edit Field for Repeater, FieldsetPage and Repeater Matrix allowing you to quickly set the widths of inputfields within the Repeater/FieldsetPage field, or within each Repeater Matrix type. Note: widths are only saved if the edit form is submitted with the "Field widths" field in an open (non-collapsed) state. Edit template Edit Field: Repeater Edit Field: Repeater Matrix Why? When setting up a new template/repeater or trying out different field layouts I find it a bit slow and tedious to have to open each field individually in a modal just to set the width. This module speeds up the process. Config options You can set the default presentation of the "Field widths" field to collapsed or open. Widths entered into the "Field widths" field are only applied if the edit form is submitted with the field in an open (non-collapsed) state. "Collapsed" is the recommended setting if you think you might also use core inputs for setting field widths in a template context. You can choose Name or Label as the primary identifier shown for the field. The unchosen alternative will become the title attribute shown on hover. You can choose to show the original field width next to the template context field width. https://github.com/Toutouwai/TemplateFieldWidths https://modules.processwire.com/modules/template-field-widths/
  21. Robin S
    I haven't yet had the need to work with the Login/Register module but given that it's by Ryan, lead developer of ProcessWire, I think it's safe to say it's a well-made module that is very ProcessWire-y. Login/Register is a relatively recent module, and I believe it's intended for scenarios where you want bog-standard login/register features without having to think much about it. It's probable not intended for scenarios where you want specific custom behaviour. In those cases you would use the PW API to code exactly the features you want, which is what people did for all frontend-user needs before Login/Register was released. Here is a forum topic and some helpful gists from @Soma that can get you started with the PW forms API: PW simple form via API: https://gist.github.com/somatonic/4027908 Create a page edit form on frontend using PW API and fields from the template of the page: https://gist.github.com/somatonic/5011926 And of course Login/Register uses the PW API so study that for sure.
  22. Robin S
    It's okay to use a page/template for an AJAX response, but if you're using a delayed output approach with an auto-appended main.php file then remember to disable that for your AJAX template: Edit Template > Files > Disable automatic append of file...
  23. Robin S
    [joke]You're gonna hate underscore.js then[/joke] ?
  24. Robin S
    @adrian, I've added a substitute getPageIndex() method to the module so the issue should be fixed in v0.1.12. Probably not as efficient as the core Traversal methods but should be okay unless you have a massive number of siblings.
  25. Robin S
    Thanks, seems like a core issue with Page::index(): https://github.com/processwire/processwire-issues/issues/751 Will see if I can find a workaround for the short term.
×
×
  • Create New...