Robin S

That's a better location for the stub files - I've switched to that in v0.1.8.

I've added support for these sorts of remote files in v0.2.1.

I don't have any fixes for this module, but I created a similar module that I have now released:

This module is inspired by and similar to the Template Stubs module. The author of that module has not been active in the PW community for several years now and parts of the code for that module didn't make sense to me, so I decided to create my own module. Auto Template Stubs has only been tested with PhpStorm because that is the IDE that I use. Auto Template Stubs Automatically creates stub files for templates when fields or fieldgroups are saved. Stub files are useful if you are using an IDE (e.g. PhpStorm) that provides code assistance - the stub files let the IDE know what fields exist in each template and what data type each field returns. Depending on your IDE's features you get benefits such as code completion for field names as you type, type inference, inspection, documentation, etc. Installation Install the Auto Template Stubs module. Configuration You can change the class name prefix setting in the module config if you like. It's good to use a class name prefix because it reduces the chance that the class name will clash with an existing class name. The directory path used to store the stub files is configurable. There is a checkbox to manually trigger the regeneration of all stub files if needed. Usage Add a line near the top of each of your template files to tell your IDE what stub class name to associate with the $page variable within the template file. For example, with the default class name prefix you would add the following line at the top of the home.php template file: /** @var tpl_home $page */ Now enjoy code completion, etc, in your IDE. Adding data types for non-core Fieldtype modules The module includes the data types returned by all the core Fieldtype modules. If you want to add data types returned by one or more non-core Fieldtype modules then you can hook the AutoTemplateStubs::getReturnTypes() method. For example, in /site/ready.php: // Add data types for some non-core Fieldtype modules $wire->addHookAfter('AutoTemplateStubs::getReturnTypes', function(HookEvent $event) { $extra_types = [ 'FieldtypeDecimal' => 'string', 'FieldtypeLeafletMapMarker' => 'LeafletMapMarker', 'FieldtypeRepeaterMatrix' => 'RepeaterMatrixPageArray', 'FieldtypeTable' => 'TableRows', ]; $event->return = $event->return + $extra_types; }); Credits Inspired by and much credit to the Template Stubs module by mindplay.dk. https://github.com/Toutouwai/AutoTemplateStubs https://modules.processwire.com/modules/auto-template-stubs/

You could change your Select Options fields to Page Reference fields. Page Reference fields are more powerful and flexible and the better choice in most cases. One of the advantages is that users can edit, sort, add and remove options for fields simply by working with the pages that represent the options. You can create a References branch in your page tree to hold the option pages for your Page Reference fields, and the Page Field Select Creator module is useful for quickly setting up new fields.

v0.1.6 released. Adds module config options to override the requirements coming from the password inputfield, so the generator can create stronger passwords than the inputfield requires.

v0.2.0 released, which adds support for File fields so that file URLs can be added the same as with Image fields. Thanks to @gmclelland for the idea. I've also submitted the module to the directory now seeing as it seems to be working well without any significant issues reported.

Hi @ryan, I see that when FileValidatorImage is installed it is automatically employed by all InputfieldImage and InputfieldFile inputfields. I assume this means that there is no downside to having this validation so there is no need to allow the user to choose which fields it applies to (e.g. only specific inputfields used on the front-end by non-trusted users). But if it's all upside and no downside then wouldn't it be better to have this module installed by default in the PW core and not as a separate non-core module?

Prefix the name with \ to specify the global space: $foo = new \SimpleXMLElement($data);

It's not documented but you can use two curly braces to achieve de-emphasised text:

That's not the same thing. They are basically the opposite of each other. The hook method above allows for a specified number of items in each sub-WireArray, with the number of resulting WireArrays not specified. WireArray::slices() allows for a specified number of sub-WireArrays, with the number of items in each sub-WireArray not specified. To illustrate:

I think the getExif() method should throw an exception if the module requirements aren't met. But the module could also check for this when it's installed. Unfortunately I don't think it's possible to include PHP extensions in the "requires" item of getModuleInfo() but the Module documentation says (after correcting typo): So the install method could be this: public function ___install() { if(!function_exists('exif_read_data')) { throw new WireException('MetadataExif requires the PHP exif extension.'); }; }

Hi @horst, Thanks for this module! It would be great if the module alerted the user somehow if the required PHP exif extension is not installed. I spent some time trying to work out why I couldn't get any data back from images and it wasn't until I saw this in the module code... if(!function_exists('exif_read_data')) return null; ...that I realised my local WAMP stack didn't have the exif extension enabled.

Yes, in this example I was saving in the admin. Thanks.

Hi @adrian, I'm having another problem with pages not being renamed when "Enable for API" checked. As a demo, here are my module config settings: {"PageRenameOptions":{"version":"1.0.5","settings":{"enableForApi":1,"renameMatchTitle":1,"renameWithoutTitleChange":"","renameUnpublishedOnly":"","includeExclude":"exclude","exemptTemplates":[],"exemptPages":[],"exemptRoles":["superuser"],"initialDifference":1,"preventManualChanges":1,"liveChanges":null,"uninstall":"","submit_save_module":"Submit"}}} In ready.php I have this hook: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'basic-page') { $page->title = uniqid(); } }); For any page using the basic-page template, the page gets a new title on every save as expected but the name is not updated. I tried turning off "Initial differences protected" in case that was related, but pages are not renamed then either.

@gebeer, I have similar concerns as @szabesz, not just about the InnoDB requirement but the MySQL >= 5.7.8 also. I think a lot of hosts and existing sites out there are not going to meet that requirement. For instance all my sites use MariaDB and as far as I know there isn't full JSON support in MariaDB yet. Could you please clarify if InnoDB / MySQL >= 5.7.8 are strict requirements for the module? And if the module will partially work with MyISAM / MariaDB / MySQL < 5.7.8 which features would not be available?

I have now, and it works perfectly. Thanks! ?

@adrian, I don't seem to be able to dump anything inside a LazyCron hook. I don't get any errors (like I would if Tracy wasn't available when the hook runs) - I just don't get any dump in the Tracy bar. Is that expected, and do you have any tips for viewing dumps made inside a LazyCron hook? Thanks.

@ryan, thanks for this new module - really looking forward to getting my hands on it! One important thing that I think is missing though is support for Image fields (the screenshots say no File fields and I figure this means no Image fields either). It's a really common need to allow avatar/profile images for members. A simple file input would suffice, but of course it would great to have things like preview before upload, front-end image resizing, and progress bar for upload (especially if front-end resizing isn't possible).

This maybe: https://www.php.net/manual/en/function.floatval.php#92563 function ParseFloat($floatString){ $LocaleInfo = localeconv(); $floatString = str_replace($LocaleInfo["mon_thousands_sep"] , "", $floatString); $floatString = str_replace($LocaleInfo["mon_decimal_point"] , ".", $floatString); return floatval($floatString); }

First thing to try would be updating the core in case it's a fixed issue - at least to the latest stable version but I recommend going with the latest dev. From what Ryan has said the dev is going to become the new stable any day now, and in general the dev is never that unstable anyway - I always build new sites on the latest dev. If that doesn't fix it the solution is probably to grant edit access to the system repeater template, i.e. repeater_your_field_name. It's never been clear to me why users with edit access to the repeater field shouldn't have edit access to the repeater template.

You're nearly answering your own question there. The key is the position number in the field (zero-indexed like all arrays). Using this field as an example... The key is the position:

You're right - it doesn't work because the selected pages are lost after save. I remember now that there was an issue with how InputfieldPage and FieldtypePage interpret "page.some_field" when it is used to refer to another Page Reference field: https://github.com/processwire/processwire-issues/issues/479 The thing is that PW has to make some consistent evaluation of what "page" is in this circumstance and it can't really know whether you want page to refer to the edited page or the repeater page. I don't have much time right now but I might come back and explore this more later.

No, but I posted a hook for using the hidden JS max filesize validation for File fields: I'm not sure if this validation is used for Image fields. Another hook that could be used to check the filesize after an image is uploaded: $wire->addHookBefore('InputfieldImage::fileAdded', function(HookEvent $event) { /* @var Pageimage $image */ $image = $event->arguments(0); $max_filesize = 150000; if($image->filesize > $max_filesize) { throw new WireException("Image $image->basename is $image->filesize bytes which exceeds the maximum of $max_filesize bytes."); } });

The dependent selects feature has only ever worked with the selector string option as far as I know.