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. ?

@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

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?

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/

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.

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...

[joke]You're gonna hate underscore.js then[/joke] ?

@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.

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.

@d'Hinnisdaël, thanks for the report. FieldsetClose needed to be excluded - fixed in v0.1.3.

In v0.1.2 I've added some warning notices in case AdminThemeUikit is installed but not in use.

No, AdminThemeDefault and AdminThemeReno do some crazy JS spacer stuff to equalise field heights. This module relies on the flex layout used in AdminThemeUikit. Possibly, but not sure what the point of that would be. The module already requires AdminThemeUikit in order to be installed and also clearly states that in the readme. And if you have AdminThemeUikit installed but you allow some users to choose a different theme then using this module is not going to be a good idea. Best just not to install it in that case.

Right you are, I overlooked that part of your post. Taking another look at it I think the issue is that you need to specify the subfield of the page you are wanting to match against. Assuming it's the title it would be: $myBlogsStart = $bl->pages->find("template=page-blog, category_relationships_conditions.title=$query, sort=title");

Personally speaking, when it comes to page relationships I use... Page Reference fields: regularly The Page Field Edit Links module can be very useful for creating new pages or editing pages directly from the field via a modal. And the AsmSelect inputfield option has support for modal page editing built-in. You might find the Connect Page Fields module useful for automatically creating two-way relationships. Parent/child structure: sometimes, when it makes sense. PageTable fields: rarely

Glad you like it. ? Done, in v0.1.1.

I've never actually used this module, but looking at the module code I think this will work: if(empty($options['pageTableExtended']) && empty($options['pageStack'])) throw new Wire404Exception();

Not sure about the selector sanitizing, but assuming category_relationships_conditions is a Page Reference field it seems like you could simplify things and avoid the issue at the same time by using the page object in the selector: foreach($page->category_relationships_conditions as $crc) { $myBlogsStart = $bl->pages->find("template=page-blog, category_relationships_conditions=$crc, sort=title"); // ...

I recommend using a virtual host for each local project - it avoids little issues like this and will be more consistent with how the site will operate when migrated to a remote host. It's not difficult to set up virtual hosts manually, although if you use a tool like Laragon it's an absolute breeze because it automatically creates virtual hosts for every project in the document root: https://laragon.org/docs/pretty-urls.html

When a page is rendered by another page PW populates a "stack" of pages that called render in an $options variable. See Ryan's comment: So if a page is accessed directly and not rendered by another page then the page stack will be empty (in fact the $options variable will not be set). So you can put the following at the top of template files that should not be directly viewable but only rendered as part of another page: if(empty($options['pageStack'])) throw new Wire404Exception();

It's the infinitely useful Console panel in Tracy Debugger: https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=console

This seems like it could be reasonable solution: disable session fingerprint when a site is on localhost. That way when developing locally the user agent is allowed to change without causing a logout. In /site/config.php: if(in_array($_SERVER['SERVER_ADDR'], ['127.0.0.1', '::1'])) { $config->sessionFingerprint = false; }

Thanks, makes sense. So a couple of solutions would be: Use an incognito window when working with dev tools device mode. Or set $config->sessionFingerprint = false in /site/config.php These are okay but still kind of annoying. The incognito solution is a bit less convenient than working within the current browser window and easy to accidentally forget when opening view links from Page Edit / Page List. And I wouldn't want to forget the sessionFingerprint setting and leave it disabled as it reduces security a bit. I wonder if there is some way the PW session fingerprint feature could detect and allow for user agent changes that specifically come from the Chrome dev tools?

For some reason enabling the device mode in the Chrome developer tools logs me out of the ProcessWire admin. I'm using Windows 10, Chrome 70.0.3538.102. Steps to reproduce: 1. Login to PW admin. 2. View the site frontend in a new tab (e.g. Home page). 3. Open the Chome dev tools, enable device mode, and reload the Home page: 4. Switch to the admin tab (where dev tools is not open) and reload - you are now logged out. Can anyone else confirm this? Is there a setting in the dev tools that would avoid this? Or is this logout behaviour something that could/should be fixed in the PW core?

The item you want to give special treatment to is the last item in the WireArray, so you could use pop() to get that item and remove it from the WireArray: Alternatively here is a more flexible approach that you can use for any item in the WireArray:

Yeah, it's not clear exactly which languages are supported but the example in the docs... ...makes me think there is some non-English language support. Good solution. Thanks for adding this feature.