poljpocket

Hi, I am working for a small-to-medium business and we have hundreds of websites out there and with a considerable percentage of those, we have a service contract set up. We're coming from WordPress and we did the switch to PW in 2021. So, still today, the majority of our long-running service contracts are about WordPress sites, trending down fast though. We're offering our clients a few things in our service contracts: Basic guarantee that their website will run and continue to run in an ever-changing environment of servers and technologies. A predefined amount of free hours to work on the website, which even includes minor design changes, adjustments and even small new features. Bigger undertakings require a new project contract though. Reduced hourly rates for work on the website if the hours go over the amount predefined in 2, using the same conditions as in 2. I have to say though that we have a LOT of clients who simply DO NOT WANT to edit their own site but have us do it for them. That's why for them, especially the second and third point above is a big plus and is also the main reason we're designing our service contracts like this. For WordPress sites, point 1 consists of updates, backups and health checks which we do in regular intervals spread out across the whole year. For ProcessWire, it's just backups and health checks and thus on average lower predefined hours in 2.

What I mean by mergeable is that if Ryan wants, he can click "Merge Pull Request". To facilitate this, I removed the examples (which would be added to the docs or as PHPdoc) and the reference to RockDevTools since there can't be a reference to a non-core module.

I have been called out for just talking and not actually doing some work repeatedly. So I followed up on @bernhard's proposal, simplified it, added a JS build system and added some example hooks for InputfieldDatetime to illustrate what this can do. It's still a draft because at this time, I am not sure if I did understand the hooks system correctly especially when dealing with callbacks. https://github.com/processwire/processwire/pull/323 What do you think? Sorry Bernhard that I removed your rockdevtools integration and example code. I am trying to get as close to a mergeable implementation as possible.

Have there been any changes to the PHP version running on your host? What PW version is it? What PHP version?

Thanks for the example, though which perfectly illustrates my points about why this doesn't need to be in the core if the core doesn't use it: RockCalendar has first-class support for JavaScript hooks. I can't show you the code but we can see it in the Changelog: This means, that your hooked method "RockCalendarPicker::settings" actively has been written as "RockCalendarPicker::___settings" by the author of the module themselves. Likely, they also added a second change to the code of the module, possibly by adding the single file right here to the code base. Right now, other than using the global variable "ProcessWire", it doesn't have anything to do with ProcessWire at all. It doesn't interact with anything in the core. The module is already loading it's own scripts supporting hooks, likely including the hooks boilerplate part already too. So what exactly do we need the proposed core change for in this situation? It's important to remember the context which is to assume there are no changes to the core's JavaScript code. Now, try to do the same adjustment for the ProcessWire core's datepicker. You can't, not even with the module in question here installed. Not even if you go to the file /wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.js and prefix every method with "___". You'll need to completely redesign the code you find in the file to support hooks like how you are demonstrating. And by the way, you don't even need to, because you can change InputfieldDatetime's time format on the server side with hooks or by reconfiguring it. Don't get me wrong: @bernhard's solution is very good and very neat and he's using it in his modules already which I love. But this also demonstrates perfectly that there is no need for a core change in order for this to work in any module outside of core. As I already pointed out multiple times, supporting hooks in the core's JavaScript means that most of the code has to be completely overhauled.

I can second that. Easy to implement and very good for CI.

Dear @bernhard, there is no reason to get defensive if people don't get you. I am sorry if I misunderstood you. Of course, the answer to your questions would be no and no. But your proposal is about adding server-sent events code to the core, not about improving the empty-trash functionality of the core. Although the latter might be a consequence of the former. Sure, you added a demo module which demonstrates a custom "empty trash" function. But that doesn't actually replace the current one and thus, you wouldn't ever add something like this to the core. And I stand by my opinion about things like this: They don't have to be in the core if the core doesn't make use of them (as I also mentioned in the JS hooks discussion). Wouldn't it be nice to turn this around? Make a proposal for an improved experience when handling the trash using SSE to accomplish it. This means, actually changing the code of the core. This, as a consequence, could mean that the core adds SSE functionality for everyone to use. And this is where your code for sure is a very good place to start. Did I understand you correctly now?

I think this being a module for now is just fine. It can easily be added to the core's module folder sometime down the road (as it was the case for example with the TinyMCE module). We absolutely should follow the project's guidelines about additions to the core: Time will tell though :)

Cleaning up image variations Warming caches ... e.g. with a clickable button and a progress bar in the PW Admin. Using RockDaemon to manage the process doing it.

Congrats @ryan on the launch of the new website. I like it a lot! Since everyone else is posting the issues they found here, I will do the same. Thanks for considering! Layering issue on the homepage This is probably best illustrated with this screenshot: You can see I am using the devtools element selector tool and my mouse is clearly over the PW logo yet the morph canvas is focused by the tool. You might need to adjust the z-index of the header. "The CMS" menu item and "A powerful/friendly/... CMS you'll love" I love that ProcessWire used to not positioning itself strictly as a CMS because it isn't. It is so much more. This is also made clear in the introductory text: So the title and the first and most important menu item both tell visitors that ProcessWire is a CMS but then the text immediately contradicts that. I am sure you talked about this. Some ideas to solve this (yes, they have caveats too): The menu item can be called "ProcessWire" or "About" The text can be called "ProcessWire is powerful/friendly/... and you'll love it!"

Hi Bernhard, very cool module! I can imagine some interesting use-cases in combination with RockDaemon. I have one question: Why are you using token-based authentication? What's wrong with the session PW provides?

Is the new server using the same backend stack as the old one? If, for example, your new server uses NGINX, your .htaccess file is completely ignored unless you transform it into a NGINX config file.

Could you please provide some more context? ProcessWire version? PHP version? Thanks.

Hi Erik and thanks for your comments. I think @bernhard got the advantages of such systems across pretty well in his own response. I also was very confused at first. The main reason @bernhard proposed this was to allow users of his modules (who are also developers) can extend the functionality of the modules he offers. Since the concept is cool and for that purpose also makes a lot of sense, he proposed this to be included in the core. And I think, this is where the main confusion for all of us comes from – it is the question why this needs to be in the core in the first place: It only needs to be part of the core if the core also makes use of it. Which means that most of the JavaScript code in the core needs to be overhauled to allow meaningful places to hook into. At this time, though, I am less and less sure if this is really needed. The current module offered I think is perfectly fine: Developers can install the module if needed or leave it be if it's not needed. We might go as far as to create a JavaScript library on NPM or similar platforms for it to be included directly in the code base of any module wanting to use it.

So I tested a bit more: The same happens on the legacy admin theme. I think it's a problem with AsmSelect: Using a Page Reference field with AsmSelect as a starting point. This is the field the family edit screen uses for parent/child relationships. When I select a page inside a modal popup (you can get any edit screen in a popup by long-pressing the "Edit" button in the page tree), I can't save. Literally nothing happens unless i click anywhere in the modal other than the select input of the AsmSelect and then the "Save" button will start working. The field config: Screencast of what I explained above on dev branch: Screencast_20250807_142909.webm @Jo J to reiterate on your suggestion, that "clicking anywhere" includes clicking on another tab. It's the same. Means, it shouldn't have anything to do with the JqueryWireTabs module. The result is, clicking anywhere will make the select field lose focus and thus the change is registered. I am using a completely vanilla Chromium 138 on Arch Linux with Wayland. Maybe it's something outside of the browser.

And for good measure, on the dev version, same story: Screencast_20250807_115845.webm

You did exactly what I did, but let me show you how it works for me. This must be a browser thing! First, I am not clicking anywhere before clicking "Save" in the popup. Nothing happens. Next, I do the same again and click (by changing tabs) before clicking "Save". Result is as expected. Screencast_20250807_114537.webm

I am assuming you are talking about something like <?php $page->pageReferenceField->has(...) If so, then it depends on how you have setup the field. Your assumption is correct that there is a difference depending on if the field allows for single or multiple values. For single values, you are actually talking to a Page and are calling it's has() method. For multiple values, you are actually talking to a PageArray and are calling it's has() method. It does not make a difference if you are looking for User though. Apart from that their properties are different from a Page's. If you have setup your field to return a single value, has() will look for page properties, as in https://processwire.com/api/ref/wire-data/has/ And if you're setup for multiple values, has() will look for pages matching a selector, as in https://processwire.com/api/ref/wire-array/has/ I think based on the examples you will want to look at multiple values. Only there can you pass a Page and see if it's actually in the PageArray.

I think this is a fluke. I am using the PW docs daily and have never noticed any problems with it. That's how your example looks to me right now. I am on Chromium 138. So you see any JavaScript errors in the console?

Hi all, I am dealing a very strange bug and I am not sure if this only happens for me, or if you have experienced the same as well. It's about the popups which open when you directly edit allowed child/parent templates in the "Family" settings. For me, sometimes they don't save (e.g. the popup closes and nothing happens). It feels intermittent and I couldn't dig deep enough yet to get to something 100% reproducible. It is now, see below. Do you guys mind trying the following: On a vanilla installation of PW, add two templates. Next, edit the family settings for one of them. Add the other template as "allowed as child" template. To my best knowledge, you could also choose "allow as parent" here. Save the template Open the corresponding family edit popup (click the template name in the list). In the popup, add the first template as "allowed as parent". To my best knowledge, that also works the other way around for allow child (see above). Now comes the sketchy part: When I click "Save" immediately, the popup closes but nothing happens (you can check the Network tab in DevTools, it shows absolutely no requests for me.). This is not the expected result. When I switch to any of the other tabs available in the popup and then click "Save", the popup closes and the changes are saved. This is the expected result. And it gets sketchier: Open the edit popup again and remove the parent entry, then immediately click "Save". Watch the changes get saved now without issue. Also, it seems as if this is completely agnostic of the PW version. It happens on the dev branch, as does it happen in all of the most recent stable versions: 3.0.246, 3.0.229 and also 3.0.210. This makes me feel like it's either a very rare and old bug or something systematically wrong on my side. Do you guys experience the same? I want to gather some more experience before I am writing an issue about it. Thank you! EDIT: Whilst testing around a bit more, I can shed some light into the issue: Instead of me needing to switch tabs, I can just click anywhere in the popup (or press TAB) to have the save happen successfully afterwards. I think I can narrow the problem down to the select field not correctly losing focus when the "Save" button is clicked immediately. That might also explain why the "remove" action is unaffected. So we should gather information about the Browsers now? Mine is Chromium 138 I tested on Brave 80 (based on Chromium 138) as well, same result. In Firefox 141, this does NOT happen. EDIT 2: It's also not any extensions interfering as far as I can tell. I have tried a vanilla browser as well for both Chromium and Brave.

Superb! Thanks

And another remark: Have you thought about potential issues with the allowIP function in combination with IPv4 NAT? I think this should at least be togglable because I might not want my whole office to get access to my staging site once I entered the password once. Also, I think your example usage of this isn't applicable: Since you are opening the link in your browser with the session, PW will pick that up and allow access anyway. Or am I missing something?

Hi Bernhard, thanks for the great addition! I have just one small remark: You are making heavy use of the functions API in this module. None of our sites have that enabled since we don't need it. I think you shouldn't rely on that in a module. Especially since you can just easily replace all your wire() calls with $this.

For exactly that reason we're always adding an ISO-Code field to languages and use that as the hreflang value. If you need help adding this, one hint: you need to show system templates temporarily to be able to mess with the language template.

I have solved this with following hook (after manually creating the page-add-created permission). Note that this only applies to the artist template and the permission name is actually a bit misleading since it's not applied to all addable checks. In my case, the result will be the same since artists would never be the creator of anything other than their profile tree. <?php $wire->addHook('Page(template=artist)::addable', function ($event) { /** @var Page $page */ $page = $event->object; /** @var Wire $wire */ $wire = $event->wire; $user = $wire->user; // only continue checks if user has page-add since just like page-edit-created, we want to reduce the permission scope. // At this point, PagePermissions will have checked for addable already, so use its result to check if (!$event->return) return; if ($wire->permissions->has('page-add-created') && $user->hasPermission('page-add-created', $page)) { $event->return = $page->created_users_id == $user->id; } }, [ 'priority' => 999, ]);