Jump to content
ryan

PW 3.0.125 – Core updates

Recommended Posts

ProcessWire 3.0.125 has several useful new $sanitizer methods and options, as well as new ways to access them directly from the $input API variable. This makes dealing with user input even easier than it was before. This version also brings updates to our translation functions and improvements to our API documentation: 

https://processwire.com/blog/posts/pw-3.0.125/

  • Like 14

Share this post


Link to post
Share on other sites

Thanks for the updates @ryan!

Going forward, what do you think should be done about the sanitizer methods included in the PhpDoc of WireInputData? These sanitizer methods are also the basis for what gets an entry in the API documentation for WireInputData.

As noted in this request the sanitizer methods included in the WireInputData PhpDoc were already out of date (i.e. incomplete). The new $santitizer methods added in 3.0.125 are also not included there. Do you think the PhpDoc of WireInputData should just aim to keep pace with new $sanitizer methods as they are added? Or now that multiple methods can be chained together...

// access sanitizer on $input as method
$q = $input->get->text50_entities('q');

...in a way that couldn't be handled as lines in the PhpDoc, perhaps it would be better to drop the list of sanitizer methods and instead include some general note about how $sanitizer methods (with a link to the $sanitizer documentation) can be used/chained with $input?

  • Like 6

Share this post


Link to post
Share on other sites

@Robin S Good point, I need to update that phpdoc in that file and will. I think it'll be more convenient for users if I keep it up to date with Sanitizer, rather than removing it completely. At least I like my code editor being able to recognize them as function calls rather than errors. As far as I know, there's not anything we can do phpdoc-wise to cover instruction methods (like text50_entities), since there's basically an infinite possible combination of them. Though will be translating the blog post into regular documentation for these new additions. 

  • Like 5

Share this post


Link to post
Share on other sites

It would be good if the new Sanitize method was the default for FunctionsAPI so you can use sanitizer($value, 'text') 

Edit:

Never mind, it is, just the opposite way around. Does it work in the same way in that you can chain them? 

Share this post


Link to post
Share on other sites

It's been some time since I read the blog-post, but I really need to ask if we need the magic functions for the sanitizer, especially the grouped ones. They're hard to document, harder to be used for automated setups – where used sanitizers are aggregated by some coded means – compared to having them as parameters and I would say they're hardly simpler for manual usage over proper parameters. Personally I'd really vote for one clear way instead of having even more ways to do the same. For me there's also the reason that I find it way cleaner to work with data a.k.a. an array of sanitizer names vs. some magic naming, but that may just be me, but I think we really need to be aware of the backdraws of having to many options to do a thing in general.

  • Like 13

Share this post


Link to post
Share on other sites

Fully agree with @LostKobrakai. I guess a well documented ->sanitize() method would do, I'd say those magic methods are more confusing than helpful.

 

Also I originally came here to comment that a "slug" sanitizer method that also handles Umlauts would be an awesome addition too. "I drink Jägerbombs" -> "i-drink-jagerbombs"

  • Like 3

Share this post


Link to post
Share on other sites
4 hours ago, MrSnoozles said:

Also I originally came here to comment that a "slug" sanitizer method that also handles Umlauts would be an awesome addition too. "I drink Jägerbombs" -> "i-drink-jagerbombs"

@MrSnoozles You could use this one: https://processwire.com/api/ref/sanitizer/page-name-translate/

Define Umlaut-Translations (ä = ae, ö = oe, ü = ue) here and it's done:  uehttp://domain.tld/processwire.admin/module/edit?name=InputfieldPageName&collapse_info=1

I drink Jägerbombs would result in i-drink-jaegerbombs

 

Or do I get you wrong on this?

  • Like 3

Share this post


Link to post
Share on other sites
11 hours ago, LostKobrakai said:

Personally I'd really vote for one clear way instead of having even more ways to do the same.

11 hours ago, LostKobrakai said:

really need to ask if we need the magic functions for the sanitizer, especially the grouped ones

+1
These magic functions are "hard" to decode when reading, at least it is a syntax no one is used to, so when people come across things like this they will just get confused. Generally speaking, it is great to have options but if more and more ways are implemented to do very same thing, then when one is looking at someone else's source code it will become harder and harder to decode it if it was written in "another dialect" of the ProcessWire API than one is used to. If this trend continues, reading ProcessWire source code will become harder than it should be.

Edited by szabesz
typo
  • Like 8

Share this post


Link to post
Share on other sites

Afraid I also agree with everyone here - too many options which I'll never remember - I'll be sticking with the traditional approach - verbosity FTW 🙂

I feel like we are on a very slippery slope here and once you go down, you can't climb back out because you might break someone's code. I have always trusted Ryan's instincts about this stuff in the past (or he has at least convinced me in the end), but this time I am not so sure.

I hate to come across as critical or unappreciative because I know that even in my own relatively simple modules I sometimes get caught up in going with too many options, so I do realize it's a tricky balance.

7 hours ago, szabesz said:

when one is looking at someone else's source code it will become harder and harder to decode it if it was written in "another dialect" of the ProcessWire API than one is used to

I think this is a super important point!!!

  • Like 9
  • Thanks 1

Share this post


Link to post
Share on other sites
10 hours ago, adrian said:

I think this is a super important point!!!

I'm probably a well-known nay-sayer around here already, but I'm still going to add my +1 to this discussion. I feel that (particularly when it comes to API design) one clean and consistent solution should be preferred, unless an alternative approach provides major benefits. Multiple options only tend to make things more fragmented and more difficult to grasp, and doubly so when you're a new user.

As such, I'm always thrilled when an update enhances the core somehow (performance, security, scalability) or makes something new possible or more streamlined (in this update valid() and validate(), plus the whitelist feature) ... but I cringe a bit when a new way of doing the same old without (seemingly) notable benefits is added.

Personally I wouldn't mind seeing the core get leaner in the future, perhaps in 4.x. There are, and always will be, features that should be added to the core (shameless plug: FiedltypeDecimal), but on the other hand alternatives without major benefits or major user base, and modules that may not be particularly often-used should, in my opinion, be stripped out.

10 hours ago, adrian said:

I hate to come across critical because I know that even in my own relatively simple modules I sometimes get caught up in going with too many options, so I do realize it's a tricky balance.

A module I've been working on recently has an "alias" feature (that isn't even that important to the module, to tell the truth), which was getting way out of hand. You could provide its arguments in five different formats, at least, which all required their own handler methods. I was working on this feature on Sunday (once again), and finally got fed up with it, stripped all those alternatives out and replaced them with one unified solution: callbacks.

Sure, a bit of syntactic sugar might've been lost in the process, but I also got rid of probably 75% of the required code, and the documentation page is now actually readable. So, yeah – I know exactly what you're talking about 😅

  • Like 15
  • Thanks 1

Share this post


Link to post
Share on other sites

I must agree as well with all those alternatives and multiple ways for the same thing.... should really stop. I lost track long time ago and 99.99% never use any of them and really don't care at all. It's utterly confusing and I completely don't understand the reason behind it. It makes it harder than it should be. So many things goes against it...

 

 

  • Like 8

Share this post


Link to post
Share on other sites
14 minutes ago, teppo said:

As such, I'm always thrilled when an update enhances the core somehow (performance, security, scalability) or makes something new possible or more streamlined (in this update valid() and validate(), plus the whitelist feature) ... but I cringe a bit when a new way of doing the same old without (seemingly) notable benefits is added.

I couldn't agree more - this was also my reaction with this latest version. 

3 minutes ago, teppo said:

Personally I wouldn't mind seeing the core get leaner in the future, perhaps in 4.x.

I was thinking of mentioning this idea myself, but I love the fact that so far we've never really had any breaking changes in the evolution of PW. But unfortunately I agree that in v4 it's time to strip out lots of the experimental ideas that just haven't taken off.

Think back to:

$pages("template=basic-page")

Has anyone here ever used that "variable as a method" approach for finding pages? I'd much rather spell it out with a get() or find() method.

I know early on I was given some grief over all the shortcut methods in Tracy, but I think that's a different situation - those are temporary bits of code that don't stick around. For production stuff I like self documenting code over shortcuts that save a few keystrokes.

I have no idea how it would be determined would would stay and what should be trimmed, but I think it's needed.

 

  • Like 9

Share this post


Link to post
Share on other sites

Same feelings also. I think Teppo really said well how I felt also when read the latest post (and discussion about api examples). 

That kind of optimization is nice per project, but it is really confusing for a platform that we use to maintain and build hundreds of websites and applications with multiple developers. 

I'm all in for introducing breaking changes for 4.0. That would get rid of compiler also.

  • Like 7
  • Thanks 1

Share this post


Link to post
Share on other sites

I think there is still a big issue for the Functions API and variable API. As my understanding we are pushing the Functions API, however, the blog posts are still using the variable API in it's examples. I'm getting really mixed messages, are we pushing the functions API or not? 

I can see this starting to get really confusing for new people coming in to ProcessWire. I can see them building websites with a mix of Functions API and variable API with little understanding of the difference. For example, they may believe that to get page data you do <?= page('title') ?> but to sanatize the data you use <?= $sanitizer->text( page('title') ) ?> 

Honestly, I think we should just push one or the other. Sometimes using one and sometimes using the other is causing a lot of confusion. We run the risk of moving into WordPress territory where there are multiple ways of achieving the same thing. We will have people asking the questions, which one or which way is best.

I just believe a decision needs to be made and run with it. At the moment, I have no idea which approach to use for my next project. I was edging towards the Functions API but I just want to use what is seen as the standard. 

  • Like 7

Share this post


Link to post
Share on other sites
Quote

The functions API is specifically built as a convenience for front-end website or application development. While it can be used anywhere, it is not intended for modules and back-end processes/hooks.

Quote

Not all API variables are available as functions. Only those that are likely to be needed on the front-end of a website or application are available as functions

https://processwire.com/docs/start/api-access/

Share this post


Link to post
Share on other sites

Disregard my comment, I didn't take some things into consideration.

Should have made it clearer what I meant though: "Considering the drawbacks I listed, i don't think the functions API should be the default".

  • Like 1

Share this post


Link to post
Share on other sites

I think this one of the most massive discussion about the project architecture I have ever read, featuring so many respected forum members, should not be left unanswered by the project lead. So feel like we need to bring it back up and ask @ryan to participate.

  • Like 9

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...