Leaderboard

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/

I hope you all have had a good start to 2020! Last week's release of the new master ProcessWire version 3.0.148 has gone smoothly, and if you haven't yet upgraded, it's a good time to do so. This week I've been working to finish up the new front-end file upload field called InputfieldFrontendFile, which is part of the LoginRegisterPro module package. I've released beta version 1 of that module in the LoginRegisterPro support board in the downloads topic, so it's ready for download now, as is a new version of LoginRegisterPro to accompany it. Today, I've written up a lot about this module, as well as posted a few screenshots here: Front-end file uploads with InputfieldFrontendFile module I've also got some ProcessWire core updates in progress this week for the dev branch, but this week has gone by so quickly I think I'll have to save those for next week. Thanks for reading and have a great weekend!

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

Brilliant! I never got into the habit of using Template Stubs (mostly since at the time I didn't use an IDE that would've benefitted from it) but I'm definitely going to give this module a try now ? One thing I'm wondering, though, is the directory for the stubs. Unless I'm misreading this, currently it needs to be under the AutoTemplateStubs module directory? This is a bit of a problem for me: first of all (as a matter of principle, mostly due to security concerns) I never allow PHP to write into the modules directory, so this would require some tweaking on a per-directory basis – and second of all it would force me to run these files through version control and a deploy process (which could also be seen as a good thing, but for the time being I would prefer to avoid that). Would you consider adding a config setting for storing these files somewhere else? That "somewhere else" could be a folder under cache, perhaps /site/assets/cache/AutoTemplateStubs/.

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

@teppo (and @Robin S who had a similar question): There is coupling from LoginRegisterPro to InputfieldFrontendFile, but there isn't any from InputfieldFrontendFile to LoginRegisterPro. So I think InputfieldFrontendFile can be used for other cases outside of LoginRegisterPro. But for the moment, I've been focused just on the LoginRegisterPro use case, so haven't tried to use it for other things yet. The main thing is that for ajax file uploads to work, the system creating and rendering the form behind it (whether ProcessPageEdit, LoginRegisterPro, ProcessProfile, ListerPro, ProcessUser, etc.) needs to recognize an ajax request for a specific field and pass control to it, rather than doing the usual form rendering or processing. Afterwards it also needs to intercept the result and provide an ajax response (like JSON). LoginRegisterPro does this exactly the same way that ProcessPageEdit does (looking for specific HTTP headers), so unless I've forgotten anything, InputfieldFrontendFile would work in PW's admin page editors too. InputfieldFrontendFile also uses Pagefiles/Pageimages objects as its value attribute (just like InputfieldFile or InputfieldImage). That's because in ProcessWire, any file has to have an "owner" that can manage files, and of course Page objects (via a dedicated PagefilesManager instance) are what do that in PW, and Pagefiles/Pageimages objects are 1-to-1 with a Page. So that's where the real coupling is, to a Page, and to a Files field (or Images field), rather than to LoginRegisterPro. It's a good fit here because LoginRegisterPro works with User objects, which are just another type of Page. What InputfieldFrontendFile can't replace is something like the file upload field in FormBuilder. In that case, the form entries are the "owners", and they are entirely different from Pages and have their own protected file storage and delivery system. Also an entry isn't allowed to exist till a form is submitted, so ajax file uploads wouldn't work there, except potentially on a paginated form after the first pagination.

I am using Contabo VPS (Germany) services since 2015 and i can recommend this company to you.

Out of curiosity, how tight is the coupling between this inputfield and LoginRegisterPro / a specific form in it? ? I'm working on a project that will require front-end uploads. It's not a huge deal – I can handle that in other ways as well – but just wondering if I could possibly use this new inputfield for those. These uploads would have nothing to do with the LoginRegisterPro module specifically, but I might still find good use for it on this particular project.

@teppo has to interview them for ProcessWire Weekly.

ProcessWire Dashboard Download You can find the latest release on Github. Documentation Check out the documentation to get started. This is where you'll find information about included panel types and configuration options. Custom Panels The goal was to make it simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people. Roadmap Panel types Google Analytics Draft At a glance / Page counter 404s Layout options Render multiple tabs per panel Chart panel load chart data from JS file (currently passed as PHP array)

FieldtypeFontIconPicker Supported Icon Libraries FontAwesome 4.7.0 Uikit 3.0.34 IonicIcons 2.0.1 Cahangelog NOTE: Module store data without prefix, you need to add "prefix" when you want to show your icon on front-end, because some of front-end frameworks using font-awesome with different "prefix". Module will search site/modules/**/configs/IconPicker.*.php and site/templates/IconPicker.*.php paths for FieldtypeFontIconPicker config files. All config files need to return a PHP ARRAY like examples. Example config file : create your own icon set. File location is site/configs/IconPicker.example.php <?php namespace ProcessWire; /** * IconPicker : Custom Icons */ return [ "name" => "my-custom-icons", "title" => "My Custom Icon Set", "version" => "1.0.0", "styles" => array( wire("config")->urls->templates . "dist/css/my-custom-icons.css" ), "scripts" => array( wire("config")->urls->templates . "dist/js/my-custom-icons.js" ), "categorized" => true, "attributes" => array(), "icons" => array( "brand-icons" => array( "title" => "Brand Icons", "icons" => array( "google", "facebook", "twitter", "instagram" ) ), "flag-icons" => array( "title" => "Flag Icons", "icons" => array( "tr", "gb", "us", "it", "de", "nl", "fr" ) ) ) ]; Example config file : use existing and extend it. File location is site/configs/IconPicker.altivebir.php <?php namespace ProcessWire; /** * IconPicker : Existing & Extend */ $resource = include wire("config")->paths->siteModules . "FieldtypeFontIconPicker/configs/IconPicker.uikit.php"; $url = wire("config")->urls->templates . "dist"; $resource["scripts"] = array_merge($resource["scripts"], ["{$url}/js/Altivebir.Icon.min.js"]); $resource["icons"]["flag-icons"] = [ "title" => "Flag Icons", "icons" => array("tr", "en", "fr", "us", "it", "de") ]; $resource["icons"]["brand-icons"]["icons"] = array_merge($resource["icons"]["brand-icons"]["icons"], array( "altivebir" )); return $resource; After you add your custom config file, you will see your config file on library select box. Library Title (Location Folder Name). If your library categorized and if you have categorized icons set like uikit and fontawesome libraries, you will have category limitation options per icon field or leave it empty for allow all categories (default). Example : output if ($icon = $page->get("iconField")) { echo "<i class='prefix-{$icon}' />"; } MarkupFontIconPicker Usage // MarkupFontIconPicker::render(YourIconField=string, Options=array) echo MarkupFontIconPicker::render($page->YourIconField, [ 'prefix' => 'uk-icon-', // Icon class prefix, if you have different prefix, default is : "fa fa-" 'tag' => 'span', // Icon tag default is : "i" 'class' => 'fa-lg', // If you have extra cutom classes, for example : icons sizes, Array or Sting value 'style' => 'your custom styles if you have' // Array or String Value ]); Theme support Search support Category support

We recently relaunched DOMiD, the Documentation center and Museum of Migration in Germany. Concept, design and implementation by schwarzdesign. Features Bilingual site with German and English A section-based design focusing on flexibility and ease-of-use for editors Multiple forms built with FormBuilder that can be placed on any page Separate feeds for news & press releases Lightning fast page loads with almost perfect ratings in Lighthouse Completely accessible and SEO-friendly Notable tech decisions Forms and form placement There are multiple forms for different services that DOMiD offers. Those are built with the FormBuilder. The editors don't have access to the FormBuilder itself, but we still wanted to allow them to control which form is displayed on what page. For this purpose, every page has a select field to select which form to include (if any). Additionally, the form placement has additional fields for a headline and a description, so a generic contact form can be reused in different contexts. Section-based design Most pages are built through Repeater Matrix sections. There are multiple section types available, for example: A generic text / image column with up to three columns of text and images An accordion (rendered as <details> elements). An image gallery Downloads (for files and images, displayed as a list of downloads) External Embed (e.g. YouTube) All sections have an optional headline and a selection of three different background colours. In addition, text columns may be rendered as a coloured block with some padding. This allows for interesting and diverse layouts. Testimonial database One of the available sections is for testimonials or statements (you can see one at the bottom of the homepage). Because one testimonial may be displayed on multiple pages and the client wanted to be able to switch the displayed testimonial on the fly, there's a separate content type for statements. The statement content type has fields for the statement text, author, and author image. The testimonial section only has a page reference field to select which statement to show. This way, the testimonial definition is separate from the placement on a page. Modules used Form Builder Pro Fields (Repeater Matrix in particular) Unique Image Variations ALIF - Admin Links in Frontend Sitemap Wire Mail SMTP Developer Tools: Tracy Debugger, Duplicator, ProcesWire Upgrade Migration museum As a sidenote for anyone living in Germany, this month the German Bundestag has approved funding for DOMiD's first Migration Museum ("Haus der Einwanderungsgesellschaft")! The museum will be build in Cologne and is scheduled to be finished by 2023. We're looking forward to it! Check out this page if you want to learn more, or find out what people are saying about it here.

Yep, now I get it ? Thanks for the tip!

If the issue is that stub files are not being synced from the server to your local environment, you can just go to the module config on your local develoment site and change the class prefix to something else (say, tpl2_) and then restore it to whatever it was (such as tpl_). Every time you change this variable stub files are removed and then recreated, so this way you can force the module to create local stub files for you. Does that make sense? ?

I think providing an option for this would indeed be sensible ? While testing the module I found it quite simple to regenerate the template stubs content on the local environment – this way there's no real need to sync stub files, and if you've got a full environment locally you can do this just by changing the prefix for something else and then restoring the old value. I'm currently running a slightly modified version of the module with a regenerate option in module config; seemed like a good idea at first, but not sure anymore. Might send a PR and let Robin decide ? Also, just in case there are other VSCode users here, a couple of pointers for getting things up and running: If you've excluded the /site/assets/cache/ directory (I had), you'll have to change the exclude setting. Sadly VSCode doesn't support full glob syntax, but ignoring everything except certain subdirectories is still doable with a hacky workaround (more discussion here) : "files.exclude": { "**/site/assets/cache/{[^A],?[^u],??[^t],???[^o],????[^T],?????[^e],??????[^m],???????[^p],????????[^l]}*": true, }, Suggested syntax for var (/* @var tpl_basic_page $page */) won't work, since VSCode expects valid PHPDoc syntax. Use /** @var tpl_basic_page $page */ instead. I'm using the PHP Intelephense plugin (bmewburn.vscode-intelephense-client), and after resolving aforementioned inconveniences things are working just fine ? Edit: sent a PR for the regenerate stubs option (https://github.com/Toutouwai/AutoTemplateStubs/pull/4).

@HMCB, thanks! So the datepicker itself is nothing fancy, it's just a style-matched version of Calendario https://tympanus.net/Development/Calendario/index2.html In Calendario, you just setup a JSON array of the events, and init the plugin with JS. The link on each date is to a URLSegment which then is processed via the API to get the events for that date. The URL segment logic was tricky because there are events with series dates (using a ProFields Table) which also need to be accounted for, but the beauty of the PW api is that it only took maybe 20 lines of code for all of the event fetching logic for single date calls. ---- also wanted to say thanks for the mention on the blog, newsletter, and SOTW! ? ---- and the SkyscrapersTurbo™ Profile is well underway, featuring rangesliders for all numeric attributes (Year, Floors, Height) and architect filter. So this version is is possible to narrow down results for very specific combinations.

To also give it a visual representation you can additionally add: $f->addClass('ui-state-disabled');

true, but sometimes I have to use that button (especially when adding a new project, and the directory list is not up-to-date, but also elsewhere...)

I know Jens, but I'd like to use same references as PW uses. An PW is not yet on ECMAScript 6.

in the upper left corner you have a reload-icon. "reload all from disk" shows on hover. Another way is to simply restart PHPStorm. Usually the IDE is then re-scanning / looking for changes. I don't know what IDE plugins I've been installing in the last couple of months, but I'm quite happy with how PHPStorm is doing autosuggest. Far from perfect though... ideally it would only show suggestions that make sense in the context (show only applicable methods). It would be nice to have a keyboard shortcut to only show page fields or something like that.

@teppo for front-end uploads you could also take a look at this example which utilizes TusPHP (resumable uploads) and Uppy (a nice uploader widget)

Note for PHPStorm users: In my case the AutoTemplateStubs directory was automatically marked as excluded (don't know from which setting this comes from) and I had to mark the directory as "not excluded" to make autocompletition work.

I'm glad you like SnipWire! ? Important: SnipWire is not yet ready for production environments! Subscriptions are on my backlog and will be definitely in the first release!

Short note for all those who use this module. In a fresh install of ProcessWire 3.0.148 this module (yes, it's only officially support until 2.7 - but still) stopped working properly. Settings like skipping existing pages/entries will be ignored and the import into date fields is not possible at all. Last working environment I can confirm is ProcessWire 3.0.133.

I am a very happy PhpStorm user.

@ozwim - not sure if you already know about this, but i follow Soma's suggestion and have a folder called 'hannas' and then keep all the hanna codes there; and then using this in the hanna code itself: include($config->paths->templates . "hannas/some-hanna-code.php"); @mr-fan - that's great - we should try and setup a place to share hanna codes... maybe github? I have a lot of examples also