Leaderboard

Upgrading the secondary site to the same version as the "mothersite" fixed the issue. As explained here: 'Ideally all instances should be running the same exact version of ProcessWire if possible. At minimum, the versions must be close.'

Hi @Gideon So, I will prepare something, but it's mostly taking advantage of the Repeating fields.

@David Karich I was working on the snapshot module for awhile, then got sidetracked on another project and lost the momentum on it. Hopefully will return to this, though now that I've been away from it for awhile, I can see I was having a lot of fun developing it but am starting to question whether it's really that useful. The language translation export/import module is currently in development and a sponsor split the cost of development with me. It is currently fully functional and in client testing right now. The major features are built but there's still a few smaller things I want to finish developing before it is ready for production use. This one is pretty close to being finished though. @szabesz The control of types is still on my radar. Are you looking for it with nested repeaters or with depth repeaters? I think depth repeaters is where people were looking for it, but wanted to confirm. The background-color for repeater matrix items was implemented last year, and should be fully functional. Where do you see the hex codes show up, in the page editor? They shouldn't be, I've not seen it, and it's not been reported before as far as I know, but if it's something you are seeing (dev branch and latest RM) please let me know.

Hello, We have been audited by a security firm regarding a new website in Processwire. The client is a financial firm and insurance companies are becoming increasingly wary of the vulnerabilities that certain libraries represent. The report mentions the two obsolete jQuery libraries that ProcessWire uses for the admin part. Although the visitor or potential hackers are not aware of the use of these libraries (and the report does indicate that the site is secure), the report still mentions a moderate risk when it comes to the administration of the site. In short, the following libraries are requested to be updated to remove these vulnerabilities. .../wire/modules/Jquery/JqueryUI/JqueryUI.js .../wire/modules/Jquery/JqueryCore/JqueryCore.js It might be time to upgrade on this side. Is it possible to do this without causing problems in the administration of the site? I can do my own tests, but I would still like to know the reasons why this is not up to date.

Supposedly this dude is rebuilding it ? Ok seriously, trying hard, but my time is also limited right now, I almost have the UI rebuilt in Alpine, just need to wrap my head around the Fieldtype interface. But I'd say it's still at like 20% - 30% I am trying to get a run at it asap to build the bare minimum, without the Markup modules, which I also need anyway lol

A couple months ago I reached out to the original author of Recurme and asked about the possibility of open sourcing the module and taking a role as maintainer. I've used this module previously and think a good calendar module is critical for the PW ecosystem. Had a great exchange with him and he was open and willing to turn over any assets needed and allow the code to be open sourced with no restrictions. As far as I know the module is still largely usable with the tweaks people have mentioned in this thread but I can't speak to more than that. I started working on refactoring the code and have a few ideas on how to improve/revamp it. I'm still enthusiastic about the idea of keeping development alive but unfortunately I just don't have the time right now to take it on with how busy I am with non-programming stuff as well as my commitment to getting the next version of my Fluency module released. I'd love to see this open sourced and would count myself as a contributor or help out where I can, but being a maintainer/lead is outside of my abilities right now. Hope there is some interest or capacity out there to make this happen.

Hi Zeka, Thank you for the suggestion. Sadly that just gives a blank array and the error 'Notice: Array to string conversion'. Stay safe my friend.

Quick note on this: I can definitely see how this could be an issue, and if you require full control over error messages then shutting down browser errors and relying on PHP defined ones instead is a good option. That being said, personally I tend to keep browser level validation enabled due to a few reasons: Although these errors are "defaults" and it's difficult to alter them (constraint validation API is an option, but at least in my experience it's a bit heavy to use), these messages should be in the language chosen by the user. Not the language they're browsing the site in, but the language they're using at OS / browser level. Thus translating to the language of the site may, in some cases, have negative consequences. Personally I like to get feedback early, and thus it feels more intuitive when errors can be displayed before sending and processing the form. Finally I prefer to rely on HTML validation if/when possible for accessibility. PHP generated errors can be added in a way that makes them properly accessible, but it takes a bit of extra work, and typically requires some JS as well. At least in theory HTML level validation features should have the widest possible support ? Anyway, just saying that there are valid reasons for both approaches — combining front-end and backend validation, vs. backend validation only.

Yes, it will break. I gave the link to the blog post introducing "owner" selectors in the code, but here it is again: https://processwire.com/blog/posts/processwire-3.0.95-core-updates/ So this selector... template=colour, select_colour.owner.template=animal, select_colour.owner.id!=$page->id ...is saying... Match pages where: the page template is "colour" and the page is selected in a field named "select_colour" and the page containing the select_colour field is using the template "animal" and the page containing the select_colour field is not the page represented by the $page variable (i.e. the page that is currently open in Page Edit)

Something that would be worth a try... Use a saveReady hook to put all the tags as space-separated values into a (hidden) textarea field. Then use the **= operator with the tags string of the current project. From the docs:

I've managed to resolve this with $session->removeAllFor('message') but I think that this should be done already with 'clear'.