Robin S
-
Posts
5,039 -
Joined
-
Days Won
340
Everything posted by Robin S
-
I think I'll leave it for now unless I hear from others who are finding it confusing. I didn't know PW had that restriction. Thanks, have merged in v0.1.8.
-
This seems like a pretty good approach to both inline and CSS images: https://css-tricks.com/using-webp-images/ For inline images in a textarea a textformatter module could prepare the picture/srcset.
-
Probably not news to anyone familiar with webp, but I just tried it and the reduction in file size is impressive indeed. WEBP image on the left generated from variation with 100% quality, JPG on the right with default PW quality setting. Interesting that there is a slight but perceptible difference in colour though.
-
How to store sessions after performing a cURL post request
Robin S replied to Tom.'s topic in General Support
Maybe SessionHandlerDB will behave differently and therefore be an alternative. -
I experienced the same issue using the PW Upgrades module. I think it is Windows-specific and relates to a bug introduced by Ryan trying to resolve this issue: https://github.com/processwire/processwire-issues/issues/704 In recent dev versions PW is not able to delete files on Windows. See also:
-
Installation cleanup not working on new dev version
Robin S replied to bernhard's topic in General Support
I can confirm the same issue on Windows with recent dev versions. I think the problem relates to commits made in an attempt to fix this issue: https://github.com/processwire/processwire-issues/issues/704 -
Thanks, I always forget about this possibility because in my default site profile I automatically derive field labels from names. Fixed in v0.1.7. It's actually deliberate the way it is. Title tooltips can be a distracting irritant when you don't have an intention to see them. I wanted there to be some intentionality required for them to appear, so you need to hover the field identifier (which is block level so it's pretty easy to mouse to) rather than having tooltips popping up whenever your mouse is anywhere inside "Field widths".
-
You mean fields inside a FieldsetTab? If so then yes, it works well.
-
v0.1.6 has a new config option to choose Name or Label as the primary identifier for fields. Whichever isn't chosen becomes the title attribute shown on hover. Thanks @tpr - in v0.1.6 I added your drag resizing code mostly unchanged. It's not something I think I'll use myself but very cool nonetheless.
-
Page reference field exclude items already used in different field
Robin S replied to ttttim's topic in General Support
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:
-
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(); }
-
Thanks @eelkenet, fixed in v0.1.4.
-
@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.
-
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
-
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?
-
Modules Directory code for parsing module info
Robin S replied to Robin S's topic in General Support
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. -
Modules Directory code for parsing module info
Robin S replied to Robin S's topic in General Support
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...
-
VisBug looks nice indeed:
-
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. ?
-
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.
-
Thanks, fixed in the latest version.
-
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.
-
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.
-
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.
-
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().
