Leaderboard

Field Initial Value For most field types, allows the definition of an initial value that is automatically set when pages are created. The initial value can be set in template context if you want a different initial value in different templates. Example for a "Countries" Page Reference field using AsmSelect: Example with explanatory notes in a CKEditor field: Differences from "Default value" The core allows setting a "Default value" for certain field types. The "Initial value" setting added by this module is different from the "Default value" setting in the following ways: The "Default value" is a setting that applies only to the inputfield, meaning that the value is shown in the inputfield by default but is not stored until you save the page. By contrast, the "Initial value" is automatically saved to the page when the page is first created. Related to point 1, when a page is created via the API rather than in the ProcessWire admin the "Initial value" is saved to the page but the "Default value" is not. The "Default value" has no effect when a field is not "required", but the "Initial value" is set for both required and not required fields. Related to point 3, a user can empty a field that had an "Initial value" applied but a field with a "Default value" set cannot be emptied. The "Initial value" setting is available for more field types than "Default value". Supported field types The following field types are supported, along with any types that extend them: FieldtypeText (includes types that extend it such as Textarea, CKEditor, URL, etc.) FieldtypeDatetime FieldtypeInteger FieldtypeDecimal FieldtypeFloat FieldtypePage (with all core inputfield types) FieldtypeCheckbox FieldtypeOptions (with all core inputfield types) FieldtypeToggle FieldtypeSelector FieldtypeMultiplier (ProField) FieldtypeCombo (ProField, only supported when File and Image subfields are not used) FieldtypeStars (third-party module) If you want to try field types beyond this you can define additional types in the module config, but your mileage may vary. Unsupported field types It's not possible to set an initial value for these field types, along with any types that extend them: FieldtypeFile (and FieldtypeImage) FieldtypeRepeater (includes types that extend it such as Repeater Matrix and Fieldset Page) FieldtypePageTable FieldtypeTable (ProField) Notes Seeing as the initial value is defined in the field config it has no idea of the current page - for the purposes of rendering the initial value inputfield the home page is supplied as a dummy page. This probably isn't an issue in most cases but it might have an effect for some Page Reference fields if they use the current page to limit the selectable pages. https://github.com/Toutouwai/FieldInitialValue https://processwire.com/modules/field-initial-value/

The form is blocked by my adblocker (uBlock origin) ? Maybe the same thing happens to you...

Yet another pretty useful module from New Zealand. Thanks a million!

Oh wow, thanks. That looks (as everything tends to be with PW) so simple!

If your two sites are on the same server then this blog post explains how to do it: https://processwire.com/blog/posts/multi-instance-pw3/

It's in the core but not installed by default. Modules > Install > ProcessPagesExportImport Blog posts: https://processwire.com/blog/posts/processwire-3.0.71-adds-new-core-module/ https://processwire.com/blog/posts/pw-3.0.70/ https://processwire.com/blog/posts/processwire-3.0.68-and-more-on-page-export-import/ https://processwire.com/blog/posts/a-look-at-upcoming-page-export-import-functions/

For me personally I see RockFrontend as a tool for development. Not a frontend framework. The main reasons why I am using RockFrontend are: - Auto Refresh - Make use of the rfGrow Feature for fluid font sizes & Handling Assets: - Auto compile LESS to CSS - Minify CSS and JS Files I know that there are already some JS-Snippets included (like rf-scrollclass) but I it's too tempting to start in including more and more Frontend Framework features. I personally use only a fraction of what RockFrontend offers and it's hard keeping track because new features arrive continuously ? If more and more frontend framework features will be included at some point in the future you have to decide wether RockFrontend will evolve into it's own frontend framework, shipping scripts and styles for everyday usages.

I've often heard people say "It's hard to keep track" with all the updates to my modules. That's why I work on the DEV branch now in all of my modules for one month and then merge the changes into MAIN and create a new release that lists all new features and bug fixes. If you are interested you can sign up here: https://www.baumrock.com/rock-monthly/ ???

Ahhhh thank you - penny drops, aha moment! ? This works - the template-specific classes need to extend DefaultPage and not Page... painfully obvious with hindsight that it should follow usual inheritance rules. I'm not 100% sure it's clear from the docs though, I think I was expecting some kind of PW magic to kick in and inject the DefaultPage methods. Either way I know now and this awesome PW feature becomes even more useful. Thanks all. ? Edit: I now also realise this is exactly what @Charming Troll's reply was demonstrating. - thanks.

Yes, I refactored my code by using URL hooks which is much cleaner anyway. Maybe. I could dig up the old code to take a look at it but the issue is not important anymore. Thanks for you support!

I should have checked first if there is new version of the module or not, I was banging on open doors... Thanks anyway, the new hookable method is very useful, and not just because I can now save custom data but because I can also skip logging saves performed by hooks only (by setting $event->return to null when a field is only changed by a hook and not by a person).

Just a thought - do you have your template specific classes extending 'DefaultPage' rather than 'Page' ? The scenario you're describing has always worked just fine for me.

Hi all, sorry for the delay I was away for a few days and thanks for the responses so far. So the contents of the class file (DefaultPage.php) are as follows: class DefaultPage extends Page { public function test() { return 'test'; } } My understanding (maybe wrongly) is that in this scenario $page->test() should then be callable in any template? However I get a method is not callable in this context error. Yes this is enabled. Testing this in a fresh download of latest production PW where is enabled by default. (Other template specific classes and methods work too - e.g. /classes/HomePage.php). Other background info is that I'm using markup regions - I don't know if that could make any difference? Thanks, J

Great, thanks! I notice is says “Development version, not yet recommended for production use” so I'll have a play with it first. ?

Hi @thibaultvdb, Thanks for your interest in Padloper 2. I have moved your question to its own topic. Yes, it should be possible to do this with Padloper 2, although the feature is not available out of the box. There are at least two approaches I can think off. Let me sleep on it. I'll give you a better response tomorrow. Thanks.

Following is how I've got it working. I haven't done major testing yet, but it appears to be working. /site/init.php (at end of file) require_once('./classes/CommonTemplate.php'); /site/classes/CommonTemplate.php <?php namespace ProcessWire; class CommonTemplate extends Page { function __construct($templates = array(), $parents = array()) { parent::__construct($templates, $parents); } function testClass() { be("This is working!"); } } /site/classes/[TemplateName]Page.php (eg: AboutUsPage.php) <?php namespace ProcessWire; class AboutUsPage extends CommonTemplate { function test() { $this->testClass(); // Works! } } This way I'm able to access methods from "CommonTemplate" in custom page classes as $this->methodName() and in actual template files it works as wire()->methodName(). So, for clarity: /site/templates/about-us.php <?php namespace ProcessWire; ?> <h1>Cool Macho HTML template stuff</h1> <?php page()->testClass(); // or $page->testClass(); // or $this->page()->testClass(); // or $this->page->testClass(); ?>

The master/main branch is now updated to version 3.0.225. Early next week I'll be adding a git tag for the version number as well. I usually like to merge dev to the master/main branch first, let it marinate for a day or two, and then tag it. That's because once we tag it, it triggers other services to pick it up and broadcast it. So letting it marinate for the weekend just adds a layer of comfort, for whatever silly reason. That's pretty much how I've always done it. When I did the merge, it reported 511 files changed, 76421 insertions(+), 23539 deletions(-), so there's quite a lot in this version. There's enough, that I'm going to need another week to document it all into a new blog post, which should be ready by this time next week. Our contributors list also continues to grow nicely with this new version. Thanks to all those that have submitted PRs, reported issues, and submitted feature requests. Big thanks to @matjazp in particular who has been helping a lot in identifying, testing, organizing and even coding the solutions for numerous issue reports. More details on this new version next week. Until then, thanks for reading and have a great weekend!

Shoutout to @matjazp! Thanks for all your help!

I'm assuming that this problem was resolved already? Just in case: sounds like your home page wasn't throwing Wire404Exception "properly", e.g. providing Wire404Exception::codeFunction as the second argument or by calling wire404() ?

@szabesz, this should be possible with the latest version of the module. There's a new hookable method ProcessChangelogHooks::getPageEventDetails: $wire->addHookAfter('ProcessChangelogHooks::getPageEventDetails', function(HookEvent $event) { // getPageEventDetails can return null to prevent saving duplicate entries if ($event->return === null) return; $event->return = array_merge($event->return, [ 'Custom key' => 'Custom value', ]); });

Not sure if I'll post every issue here, but at least here's the first one ? --- Hey there, RockStar developers! ? What's new in the Rock Universe? ? baumrock/AdminStyleRock v1.3.0 Make your ProcessWire backend truly yours with the latest AdminStyleRock update! Version 1.3.0 brings a super cool feature that allows you to effortlessly set a custom logo in the ProcessWire backend. Your admin experience just got a whole lot snazzier! ? ? baumrock/RockFrontend v3.3.0 Get ready for greatness with RockFrontend v3.3.0! We've introduced exciting new features, including static site rendering and a nifty view-folder feature. The top bar's hidden style has been polished for that sleek look. While we're working on documenting these gems, be sure to explore and experiment with these additions! ? ? baumrock/RockShell v2.1.0 Our new db:download command streamlines database management even more. And here's a treat: an alias for your laptop lets you simply call "rockshell db:pull staging." Say goodbye to the lengthy commands and hello to efficiency! ?️ ?️ baumrock/RockMigrations v3.29.0 Prepare to be wowed by RockMigrations v3.29.0! This version brings a fresh approach to shipping your modules with custom page classes. Plus, our new path helper methods ensure your paths are on point, with normalized separators and no more pesky multiple slashes. Another really helpful feature was added to RockMigrations this month, but then removed because it's now part of TracyDebugger itself! Say hello to the "Redirect Info" section in the "Request Info" panel! Have you ever been redirected by something and didn't know why? That belongs to the past as you can now clearly see that the redirect was triggered by line 3 in /site/templates/home.php  ? Sneak Peek: Exciting Commercial Modules We've got some fantastic updates brewing for our commercial modules, slated for release soon. Brace yourselves for RockCommerce, the power behind the shop on baumrock.com, where you'll find our incredible modules up for grabs. And speaking of modules, RockPdf has been making monumental strides. It's now responsible for crafting the invoices that accompany every order. ?️ ? Stay Connected: As we rock and roll into the future of development, there's plenty more where this came from. Stay tuned for more exciting updates, innovative features, and game-changing modules that will take your projects to new heights. Thank you for being part of our developer community. Your passion and feedback keep us strumming along. Until next month, keep coding and keep rocking on! ?? Keep rocking, Bernhard

You could create a template and page to output the settings page image and specify that URL in the theme setting. Simplification: if your settings page doesn't have a PHP template yet, you could use that one, or you could extend the existing one. With url segments, you could even pull different stuff from it (logo image, icons, disclaimer, ...). Code for settings template: <?php namespace ProcessWire; if($input->urlSegment(1) === 'logo') { wireSendFile($page->logoimage->filename, [ 'exit' => true ]); } Then just put /path/to/settings/page/logo/ into the logo image file field.