Leaderboard

The next dev version of ProcessWire is in progress but I'll wait till likely next week to bump the version. So far there are 6 new pull requests added since 3.0.179 and 2 issue resolutions, plus some other updates, with plenty more on the way. A lot of focus this week has also been on FormBuilder updates which include new spam filtering options, improved save-to-page options, improved Combo field support, new entries actions (and the ability to add more via modules and hooks), framework updates, and various minor bug fixes. This version has a lot of nice improvements and I'm hoping to have it ready for you in the next week or so. More details soon. Have a great weekend!

Here is my website, built with ProcessWire, and still being refined as I learn more. https://robpackerphotography.com/ My website journey has taken me via plain html, Singapore (anyone remember that?), Wordpress, modx, and now finally PW. Along the way I experimented with drupal, concrete, silverstripe and a few others that I'd rather forget. All self-taught and done between full-time work, family and a passion for photography. I have found using ProcessWire relatively simple - despite the steep learning curve of having to learn about php... The community support is fantastic.

I made a small update where you can now output the QR Code on the front-end by calling the field directly (instead of rendering the inputfield) and I added the option to output the image in either .svg or .gif (if .svg, you'll have the additional ability to output the markup directly, instead of a base64).

https://github.com/chrisbennett-Bene/AdminThemeTweaker Inspired by @bernhard's excellent work on the new customisable LESS CSS getting rolled into the core soon, I thought I would offer up the module for beta testing, if it is of interest to anyone. It takes a different approach to admin styling, basically using the Cascade part of CSS to over-ride default UiKit values. Values are stored in ModuleConfig Module creates a separate AdminThemeTweaker Folder at root, so it can link to AdminThemeTweaker.php as CSS AdminThemeTweaker.php reads the module values, constructs the CSS variables then includes the CSS framework Can be switched on and off with a click. Uninstall removes everything, thanks to bernhard's wonderful remove dir & contents function. It won't touch your core. It won't care if stuff is upgraded. You won't need to compile anything and you don't need to touch CSS unless you want to. It won't do much at all apart from read some values from your module config, work out the right CSS variables to use (auto contrast based on selected backgrounds) and throw it on your screen. You can configure a lot of stuff, leave it as it comes (dark and curvy), change two main colors (background and content background) or delve deep to configure custom margins, height of mastheads, and all manner of silly stuff I never use. Have been developing it for somewhere around 2 years now. It has been (and will continue to be) constantly tweaked over that time, as I click on something and find something else to do. That said, it is pretty solid and has been in constant use as my sole Admin styling option for all of those 2 years. If nothing else, it would be great if it can provide any assistance to @bernhard or other contributor's who may be looking to solve some of the quirkier UiKit behavior. Has (in my opinion) more robust and predictable handling of hidden Inputfields, data-colwidths and showIf wrappers. I am very keen to help out with that stuff in any way I can, though LESS (and any css frameworks/tools basically) are not my go. I love CSS variables and banging-rocks-together, no-dependency CSS you can write with notepad.

Thanks to the excellent feedback from @matjazp , have re-vamped way the whole module works. Minimizes potential conflicts and was just a better idea. Now draws CSS variables, conditionally loaded source CSS and framework CSS together to generate single minified CSS file, with version control link to refresh cache for other pages. Only occurs when the module is visited, as it should, and after that other pages draw the minifed CSS straight from cache. Now loads in parallel with other CSS. at somewhere around 30ms, same as other CSS files. First load (in the module itself, not subsequent pages) comes in around 17 kB compressed (somewhere around 96kB uncompressed and with all options selected), so considerable improvement, especially given the elimination of almost all processing overhead. Very happy I was prodded into action. Took a little time, but I am much happier going forward. As part of the re-working, I am in the process of splitting up CSS for conditional loading according to user selections. Opens up a far greater range of user options, which I am rolling out to module as I go. As a bonus, splitting the source CSS up is making it easier for me to track and alter, allowing me to simplify the CSS and balance specificity better. Always nice when file sizes are going down, not up even though you are adding new stuff :)

It's not exactly what you're asking for, but it could be helpful or a first approach to solve your problem: In a ProcessWire multi-instance environment, I needed to get the logged-in user of the central PW instance in all the others and found the following solution. Requires to use different session cookie names in each installation and SessionHandlerDB installed. $config->sessionName = wire0; $config->sessionName = wire1; https://github.com/processwire/processwire-issues/issues/1294#issuecomment-759351593

Ok, got it. There needs to be two actions to rename a image in the file system, and in the page's record: $p->of(false); $p->singleImage->add($remoteUrl); //grab the image. $p->save(); $image = $p->singleImage->first(); //load up image that was just saved. $newFilename = $parentName . '-' . $childName . '.' . strtolower($image->ext()); $p->of(false); $image->rename($newFilename); $p->singleImage->rename($image, $newFilename); $p->save(); //save changes to page. First, rename the image in the file system: $image->rename($newFilename); Then make the rename to the page/image record: $p->singleImage->rename($image, $newFilename); That works, and now my images have the names I am looking for. Thank you all for your help!

You can always add additional parameters to a subscription. See the example here: https://github.com/danielstieber/SubscribeToMailchimp#usage

If a user is succesfully loggedin in another instance you can force login in the current (only if the user name matches) – no password required. Checkout the code I posted: and add this: $xy->users->setCurrentUser($_user); // search for this wire('session')->forceLogin($_user->name); // add this I would assign profile-edit permission only in the main instance. All this needs a bit coding experience. Be careful and don't create security holes!

Nice photos. Do you have any issues with image theft posting relatively hi-res images without watermarks? I have quite a lot of photos on one of my personal websites, but they are scaled down and watermarked, and even then, I've found some of them pop up on other people's websites without anyone asking permission. I inherited a camera club website made with Concrete, and the performance was terrible, and the editing process was horribly easy to mess up even if you mostly knew what you were doing. ProcessWire has nice image handling capabilities.

I can provide a module for this usecase: https://github.com/kixe/AdminHidePageTreeByRole ... or try one of them: https://processwire.com/modules/admin-restrict-page-tree/ https://processwire.com/modules/admin-restrict-branch/

/** * allowed flag constants (bitmask) for context * @see core/field.php * */ Field::flagAccess // 32 Field::flagAccessAPI // 64 Field::flagAccessEditor // 128 /** * set context via fieldgroup * @see core/fieldgroup.php * */ $fieldGroup->setFieldContextArray($field_title->id, ['flagsAdd' => 192, 'flagsDel' => 32]); $fieldGroup->saveContext(); /** * set context via fields * @see core/fields.php * */ $field_title = wire('fields')->get('title'); $field_title->addFlag(128); // runtime wire('fields')->saveFieldgroupContext($field_title, $fieldGroup); not tested, but should work

Sounds like you are a little afraid of hooks ? My post here might help: https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?do=findComment&comment=158164 I've even added a new comment how to find things out in the IDE (without having to dump the results using tracy)

First off I would recommend re-reading this part of the hooks documentation: https://processwire.com/docs/modules/hooks/#conditional-hooks. If we take a closer look at your second code example, here's what it's trying to do: Add hook after the saveField() method of the Pages class has been executed ... but only if the first argument to saveField() contains string value "snipcart_item_image" Now, if you look at the definition of Pages::saveField() ... * @param Page $page Page to save * @param string|Field $field Field object or name (string) ... you can see that the first argument is actually a Page, not a string. In other words your condition doesn't really make sense here — what you're probably looking for is the second argument, which is the name of the field as a string or Field object. The conditional hooks documentation explains how to access a specific argument: $wire->addHookAfter('Pages::saveField(1:snipcart_item_image)', function($event) use($item) { Note: as you can see from the second @param definition, saveField() can receive either a string or an object. If there's a way to target both with conditional hook format, it's something I'm not aware of. I'm afraid that you're making things a bit complicated for yourself by trying to use the conditional hook syntax; it's an advanced feature that has it's use cases, but it's often easier to just hook into some method and "return" if the arguments are not what you are looking for. But, alas — there's a potentially much bigger problem here: when you save a page, ProcessWire doesn't call saveField() for each field individually. I don't know in what context you're trying to make your hook work so I can't say right away how you should write this hook, but I'd be interested to know if you gave my earlier example a try... and if so, did it do anything? If you're trying to change the value right before the page gets saved in the admin, you most likely should be hooking into Pages::saveReady. Or you could hook into Pages::savePageOrFieldReady if you also want to catch single field saves ? Edit: keep in mind that even if you hook into Pages::savePageOrFieldReady, the field name (second argument for said method) is only populated if a single field was saved. The value is not going to be there if an entire page was saved. If you take a look at my previous reply and change it the code sample to use Pages::savePageOrFieldReady, it should actually be pretty close to catching both "full page saves" and single field saves.

I've put huge amounts of work into that module in the last few days. I had to take two steps back to take the next step forward: It turned out, that I needed a more robust and flexible setup when dealing with date ranges. And what I did is - thinking about it now - quite obvious: A RockDaterange now consists of two RockDatetimes. I've put a lot of effort into developing the RockDatetime module. It is already available on Github and has lots of examples and docs in the readme: https://github.com/BernhardBaumrock/RockDatetime Highlights: // calculating FROM/TO for RockDaterange case 'hour': $from = new RockDatetime("{$obj->date} {$obj->time}:00:00"); if($isTo) $to = $from; else $to = $from->copy()->move("+1 hour"); break; // check if FROM starts at 00:00 on that day if($this->from->equals($this->from->firstOfDay()) ... // formatting $d = new RockDatetime("25.02.2020 14:00"); echo $d->format(); // 25.02.2020 14:00 echo $d->format("%A, %d.%m.%y (%H:%M Uhr)"); // Dienstag, 25.02.20 (14:00 Uhr) echo $d->format(['time' => "%H|%M|%S"]); // 25.02.2020 14|30|00 I've also totally rebuilt the date parsing engine! Finding pages using the API $tpl = "template=event"; $pages->find("$tpl,range=2020"); // find all events in 2020 $pages->find("$tpl,range=2020-02"); // find all events in Feb 2020 $pages->find("$tpl,range=2020-02-26"); // find all events on 26. Feb 2020 // other possible selectors $pages->find("$tpl,range=2020-02-10 - 2020-02-20"); $pages->find("$tpl,range=2020-02-10 7:30 - 17:30"); $pages->find("$tpl,range=2020-02-10 7 - 9"); $pages->find("$tpl,range=2020-02-10 12:00 - 2020-02-20 18:00"); // find events in Feb 2020 sorted by range duration $pages->find("$tpl,range=2020-02, sort=-range.duration"); Creating pages using the API $p = new Page(); $p->setAndSave("range", "2020"); // from = 2020-01-01 00:00:00 // _to = 2020-12-31 23:59:59 // to = 2021-01-01 00:00:00 $p->setAndSave("range", "2020-12-24 16:00 - 18:00"); // from = 2020-12-24 16:00:00 // _to = 2020-12-24 17:59:59 // to = 2020-12-24 18:00:00 Formatting in action: // left column echo $range->format(['date' => "%A, %d.%m.%Y", 'time' => '']); // right column echo $range->format(['date' => "%a, %d.%m.%Y"]); Note that the last date does NOT show "07.03.2020 09:00 - 07.03.2020 12:00" - since the event ends on the same day as it starts we don't show that date again. RockDaterange will take care of all those tedious details!