Jump to content

$_GET or $_POST vs WireInputData


mindplay.dk
 Share

Recommended Posts

@ryan I've been poking through ProcessPageList, ProcessPageEdit and ProcessPageAdd for a module I'm tinkering with.

I was wondering, how come WireInputData is not used consistently throughout ProcessWire?

Many of these modules directly access $_GET and $_POST, and in my case, I'm snooping/injecting on certain GET/POST variables, and this code has to be tailored to each specific module/function, because $_GET and $_POST are copied (rather than referenced) by WireInput.

EDIT: to clarify - if you wanted to inject a GET-variable (from a hook) you would have to either inject the value into both wire('input') and $_GET[], and/or figure out how/why the individual module/function accesses a particular GET-variable.

Is this just an artifact of an incomplete effort to move away from direct $_GET and $_POST access?

Link to comment
Share on other sites

Is this just an artifact of an incomplete effort to move away from direct $_GET and $_POST access?

Pretty much. The $input API var didn't exist before some of the other code did. And the code you mentioned (PageList, PageEdit, PageAdd) is some of the oldest code in the system. Since most of what happens during these processes actually happens in other modules, this code doesn't see much action… no squeaky wheels there, so I tend to leave it alone. But when I'm working in a file that might have some older code (like that referencing either $_GET or $_POST), I'll usually change it over to use $input instead. Granted it doesn't matter that much at present, but I prefer $input for consistency.

The only benefit that $input->get/$input->post are delivering at present is abstraction from the magic_quotes setting. Longer term, I plan to connect some of the sanitization methods with $input vars so that you an pull variables pre-sanitized. So I think using $input is a better practice, but won't feel strongly about it until we're delivering more value as a result of it.

I know there are a lot of people that think there must always be layers on top of PHP's native input variables in any framework. I'm not one of them. $_GET and $_POST (and their friends) are universal, instantly understandable and always portable. Eventually there won't be any $_GET or $_POST references in PW's core. But I don't see any problem with others using $_GET/$_POST in templates if they want to.

  • Like 1
Link to comment
Share on other sites

It was fine for my purposes, the two API points I'm using do use the abstraction - not consistently, but in the two conditions that affect my module.

Here's the module, by the way:

https://github.com/mindplay-dk/ProcessPagePin

This is another one of those small features I think should be standard - I wouldn't ship a solution without this module. I think it's more a matter of developer preference than client preference - the client, I think, would either prefer this behavior, or perhaps not care if they didn't know it was an option. I'd prefer to see something like this already available to install out of the box, but I know you're a minimalist, and I actually appreciate that about you, so - hopefully those who want this behavior will find my module.

It's such a small thing, it almost seemed silly to do it as a module though... but it was educational, and I feel increasingly like I can make PW do just about whatever I want - something I've never felt with another CMS! :)

  • Like 4
Link to comment
Share on other sites

Nice Idea, reminds me of the modules I was doing to improve usability here and there like the "stay on tab" feature when editing/saving the page.

One thing that wasn't obvious at first glance, is that you can get back to where you were using the breadcrumb. If you click on the parent you'll get back to the page list with the page hierarchy open. This is something I learned to love, because it is optional. I don't think I like when the tree alway is open where I left, because I might don't want to go there and it's making assumptions... This is also one reason of why Ryan don't liked to implement such a feature (it was discussed a while back).

Link to comment
Share on other sites

One thing that wasn't obvious at first glance, is that you can get back to where you were using the breadcrumb.

No, I've been aware of that for a long time - it just doesn't really work for me. Most of the time, I intuitively hit the PAGES link when that's where I want to go. Having to first think about where to click seems counter-intuitive to me. Going back to the page list is possibly the most common and frequent operation, so I don't want to have to stop and think just to do that.

I don't think I like when the tree alway is open where I left, because I might don't want to go there and it's making assumptions...

Every UI makes assumptions - I don't like the assumption that I would need to go back to the sitemap having absolutely nothing open at all. How often do you edit one of your root pages? In my experience, they are the least likely to be edited - much more likely you're going to edit, say, a few articles in the same folder, a few products in the same category, etc.

I've already had a couple of people tell me how annoying it is that you return to a fully collapsed page list all the time, which tells me that other people intuitively click the same place too - it just doesn't seem like something you should need to think to do.

Anyhow, the module is working nicely on two sites already, so I will tag this as 1.0.0 and submit my first official module listing, woo hoo :)

Oh, before I submit this, one quick question - you guys think the name makes any sense?? I'm open to ideas.

  • Like 1
Link to comment
Share on other sites

Great module! I'm testing here and it seems like a nice usability improvement. I'm going to use it on my site for a little while to test, but already thinking I agree this might be good to have standard… perhaps as something that can be enabled/disabled from the ProcessPageList module settings. Maybe a good core addition for the upcoming 2.3 version.

As for module name, I think you've got a good name except for the 'Process' part, which we usually reserve for modules that extend the Process class. I would instead suggest maybe PageListPin or something like that?

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...