Leaderboard

Another option is to use the Toggle InputField: https://processwire.com/blog/posts/pw-3.0.139/#new-toggle-field as it has a "Default selected option" (yes / no / no selection) setting among other useful settings.

FieldTypeOptions gives you different UI and stores data in a different way. If you just need a checkbox, I'd go with InputfieldCheckbox. Less overhead.

You would use $county->setOptions($optionsArray) to populate the select options. Example: /** @var array $optionsArray */ $optionsArray = $pages->findRaw('template=basic-page', 'title'); // returns an array with page ids as keys and page titles as value $county->setOptions($optionsArray); // each option will have value="{pageID}" and label page title You need to adjust the selector to your needs.

Yes it can, but not via the field settings in the GUI. You can put this hook code in site/templates/admin.php above the require($config->paths->core . "admin.php"); line: // sets field checkbox to checked on new pages with template basic-page $wire->addHookAfter('Pages::saveReady', function (HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); if ($page->isNew() && $page->template->name == 'basic-page') { $page->checkbox = 1; } }); You just need to adjust template and field name. Everytime a new page with that template is created the checkbox will be checked by default. If you have TracyDebugger installed, you can do this with a one-liner in the Tracy console in the backend: $pages->find('template=basic-page, include=all')->each(function($p) { $p->setAndSave('checkbox', 1); });

Hi everyone, I would like to showcase a small micro site of own studio - 7studio.eu Personally I don't like to design anything for myself (as most projects lands in the trash or on the shelf), but I needed something new and simple quite fast before building a fully fledged portfolio, so I thought to built a small "starting point". This is more like a work in progress, than a finished site, it contains only basic info, screenshots of some of the latest works and that's it - as for now ? Technically, on the front end we have a simple custom HTML5/CSS3/JS code, on the back end site uses only core PW features (there is more features already built in on both backend and frontend but not published yet). Any comments, suggestions are welcome, hope you will like it and have a great weekend everyone! P.s. Sorry - there is no english translation yet, PW multilingual features will land in the upcomming weeks ?

But then why not use a fieldset, in which case it doesn’t depend on the screen layout?

@adrian thanks a lot for your script. I inherit a ProcessWire site and the admin user they gave me didn't work. With your script I was able to login successfuly. The only difference is that I put the code in the index.php file, at the end of the try block.

but when they are it's nice, especially when you hide them initially and only have to click once to open the whole row.

I'm also not saying there's only one way of doing it. I just tried to invite you to think out of the box and leave paths that you have been using in the past. That does not mean you should forget them of course, because as already said you can also use PW in a traditional database table way. It's just not the most common way I guess (which is a shame imho because PW can be a great platform not only for building websites but also as a framework). Thx, that's a very good example. What you could do here is to create two templates: "protocols" and "protocol" The "protocol" template would hold all the fields necessary for storing data for each protocol. That would be similar to all the columns needed when storing that in a DB table. For example: title, datetime, message For the "protocols" template it would be enough to have a single "title" field. Then you create the parent-child relationship on those templates. You set the allowed children of "protocols" to "protocol" and the allowed parents of "protocol" to "protocols". Then you create a new page in the page tree and choose "protocols" as template. You can set the title to whatever you want, eg "My shift protocols". Then go back to the page tree and add a page UNDER the just created protocols page. As only "protocol" pages are allowed as children you should only be able to add such a page here. Then you can populate all fields (title, datetime, message - which could be your ckeditor field) and save that page. --> You have created your first protocol entry, which would be similar to inserting a new row in the DB table in a usual database world. So that's an easy example of how you can approach such things. There are many benefits of doing it that way rather than doing everything by hand: You have a GUI for adding, editing, deleting etc. those entries. You can use all kinds of fields for adding "content" to your entries, for example it's extremely easy to add an images/files field to upload images/files. That would be very much work with plain PHP/MySQL Every "protocol" entry is a PW page and you can do all kinds of great things with it. For example you could create a template file for that page (/site/templates/protocol.php) and you would have a publicly available digital version of your entry. As PW is built apon the page-tree paradigm you don't need to create "routes" or "endpoints" - they are already there. Out of the box, as soon as you add the mentioned template file. So in our example we could access that entry under yoursite.com/my-shift-protocols/demo-entry (where the parts of the url are the names of the created pages and you could of course make them random or auto-increment or things like that). You can change some kinds of that GUI easily via GUI or via code. For example you could change the label of the "title" field to something like "Enter your name here". You have a great system for access control on a field level. You can hook into every single aspect of your GUI. No limits. Multi-Language? Yep, easy to add! And many many more things. To be fair, there's also one thing that I've been missing when working with database-like data: Grid-Views. We have the page-tree which is great for websites, but it's limited when it comes to tabular data views. We also have Lister and ListerPro, but that's not great for such use cases imho. That's why I built RockGrid, which makes it possible to list ProcessWire pages as grid with other helpers like batch editing rows and adding custom actions, see https://processwire.com/talk/topic/26663-need-help-making-sse-work/?do=findComment&comment=220918 if you like and if you are bored ? Of course you could always just code some custom view just like you'd have to do when building such an app with PHP/MySQL or any other framework. You can do that in the PW backend (https://processwire.com/talk/topic/17709-how-to-create-custom-admin-pages-aka-processmodules-yes-its-that-simple/ ) or you just code your own custom frontend for it. Now that we have everything in place you can easily listen to events in the PW ecosystem: <?php // site/ready.php $wire->addHookAfter("Pages::added(template=protocol)", function($event) { $page = $event->arguments(0); // send email $mail = new WireMail(); $mail->to('your@mail.com'); $mail->from('robot@yoursite.com'); $mail->subject('new shift entry'); $mail->body("See here: ".$page->editUrl(true)); $mail->send(); }); Now whenever someone creates a new protocol page you get an email that shows the url where you can edit and review that new entry. Hope that makes sense! Have fun exploring PW ? PS: Wondering what "INSERT INTO ..." would be in PW? <?php $p = new Page(); $p->template = 'protocol'; $p->parent = $pages->get(123); // page id of your parent page $p->title = "John Doe"; $p->datetime = strtotime("2022-11-11 11:11"); $p->message = "Your shift message"; $p->save();

@bernhard Thanks! ? I was looking for a nice way to compile some SCSS (Bootstrap in my case) the other day and as Sassify has not been updated for almost 4 years I had a look into your Scss module. It might not have been your intention, but as this a viable wrapper for scssphp I could use it for my case as well. Maybe this can be a starting point for somebody else looking for a way to compile something else than the PW core: <?php $compiler = $modules->get('Scss')->compiler; $input_scss = $this->wire->config->paths->templates."scss/custom.scss"; $bootstrap_scss_path = $this->wire->config->paths->templates."bootstrap/scss"; $output_css = $this->wire->config->paths->templates."css/bootstrap_custom.css"; $output_map = $this->wire->config->paths->templates."css/bootstrap_custom.map"; $compiler->setSourceMap($compiler::SOURCE_MAP_FILE); $compiler->setSourceMapOptions([ // relative or full url to the above .map file 'sourceMapURL' => $output_map, // (optional) relative or full url to the .css file 'sourceMapFilename' => $output_css, // partial path (server root) removed (normalized) to create a relative url 'sourceMapBasepath' => $this->wire->config->paths->root, // (optional) prepended to 'source' field entries for relocating source files 'sourceRoot' => '/', ]); $compiler->addImportPath($bootstrap_scss_path); $compiler->setOutputStyle("compressed"); $result = $compiler->compileString('@import "'.$input_scss.'";', $this->wire->config->paths->templates."scss"); file_put_contents($output_map, $result->getSourceMap()); file_put_contents($output_css, $result->getCss()); ?>

You can use the User::changed hook to do what you want (see https://processwire.com/api/ref/wire/changed/). Put this in site/ready.php: $wire->addHookAfter('User::changed', function ($event) { if($event->arguments(0) === 'pass') { $user = $event->object; $this->wire->log->save('password-changes', "User $user->name has changed their password"); } }); Now everytime a user changes their password, it will be logged to Setup->logs->password-changes. You can do similar thing with roles if($event->arguments(0) === 'roles') { $user = $event->object; $oldRoles = $event->arguments(1); $newRoles = $event->arguments(2); // code to compare $oldRoles/$newRoles // write to log } If you want to have that information in the session log, just do $this->wire->log->save('session',...)

The documentation could be clearer in this regard, and I'm probably oversimplifying here, but there two basic categories of selector usage in PW. 1. Methods that use the PageFinder class - common ones would be $pages->find($selector), $pages->get($selector), $page->children($selector). Also find/get selectors for $users. Those are the ones that spring to mind, although there might be a few more. These methods do a database query behind the scenes. 2. All other methods that accept a selector, for example $some_pagearray->find(), which is actually WireArray::find(). These methods do not query the database but work on items that are in memory. There are differences in the ways that these two categories of selector usage are implemented. Some things work in a PageFinder selector that don't work in an in-memory selector. The documentation for Selectors seems to be assuming the reader is interested in PageFinder selectors because there are code examples there that won't work with in-memory selectors. There isn't any definitive list of the differences (that I know of), but here are some things that I have found do not work with in-memory selectors (but do work with PageFinder selectors): 1. Datetime values as strings, e.g. "some_datetime_field>today" 2. Page statuses as strings, e.g. "status!=hidden" 3. OR groups In a perfect world selectors would work the same everywhere and you wouldn't have to think about it. There's an open request for this here.