ryan Posted January 25, 2019 Share Posted January 25, 2019 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/ 14 Link to comment Share on other sites More sharing options...
Robin S Posted January 25, 2019 Share Posted January 25, 2019 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? 6 Link to comment Share on other sites More sharing options...
ryan Posted January 27, 2019 Author Share Posted January 27, 2019 @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. 5 Link to comment Share on other sites More sharing options...
Tom. Posted January 31, 2019 Share Posted January 31, 2019 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? Link to comment Share on other sites More sharing options...
LostKobrakai Posted January 31, 2019 Share Posted January 31, 2019 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. 13 Link to comment Share on other sites More sharing options...
MrSnoozles Posted January 31, 2019 Share Posted January 31, 2019 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" 3 Link to comment Share on other sites More sharing options...
wbmnfktr Posted January 31, 2019 Share Posted January 31, 2019 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? 3 Link to comment Share on other sites More sharing options...
gmclelland Posted January 31, 2019 Share Posted January 31, 2019 @ryan Is the code examples correct on this page? https://processwire.com/api/ref/sanitizer/min/ https://processwire.com/api/ref/sanitizer/max/ It looks like it is missing the first argument in the function calls? $n is defined, but isn't used. Thank you for all your work in updating the documentation. Link to comment Share on other sites More sharing options...
dotnetic Posted January 31, 2019 Share Posted January 31, 2019 I also agree with @LostKobrakai 3 Link to comment Share on other sites More sharing options...
szabesz Posted January 31, 2019 Share Posted January 31, 2019 (edited) 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 January 31, 2019 by szabesz typo 8 Link to comment Share on other sites More sharing options...
adrian Posted February 1, 2019 Share Posted February 1, 2019 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!!! 9 1 Link to comment Share on other sites More sharing options...
teppo Posted February 1, 2019 Share Posted February 1, 2019 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 ? 15 1 Link to comment Share on other sites More sharing options...
Soma Posted February 1, 2019 Share Posted February 1, 2019 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... 8 Link to comment Share on other sites More sharing options...
adrian Posted February 1, 2019 Share Posted February 1, 2019 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. 9 Link to comment Share on other sites More sharing options...
apeisa Posted February 1, 2019 Share Posted February 1, 2019 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. 7 1 Link to comment Share on other sites More sharing options...
Tom. Posted February 7, 2019 Share Posted February 7, 2019 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. 7 Link to comment Share on other sites More sharing options...
fbg13 Posted February 7, 2019 Share Posted February 7, 2019 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/ Link to comment Share on other sites More sharing options...
Tom. Posted February 7, 2019 Share Posted February 7, 2019 3 hours ago, fbg13 said: https://processwire.com/docs/start/api-access/ I am very aware of what the functions API is vs the variable API. I'm mostly talking from the perspective of a new user coming into ProcessWire. 1 Link to comment Share on other sites More sharing options...
fbg13 Posted February 7, 2019 Share Posted February 7, 2019 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". 1 Link to comment Share on other sites More sharing options...
Ivan Gretsky Posted February 21, 2019 Share Posted February 21, 2019 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. 9 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now