poljpocket

What module are you talking about?

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.