ryan Posted November 9, 2012 Share Posted November 9, 2012 IMO it open some inconsistency with the system I don't like. I like the way it is and client should deal with it and it should always be same, that's why PW is so great. I'm personally not keen with having possibility to change the process to different behaviors and inconsistency throughout the system. I'm not looking to change the behavior here. I'm with you, I like the way it works. But if there are ways we can make it more hookable and customizable for specific needs like those in this thread, I think it's a good thing. I have found that a few people have asked why creating a page is a two step process. If you're automatically setting the name and title, and there's only one template that can be used, then, yes, it should be a one-step process. If it were a one-step process, that page would need to be created behind-the-scenes as soon as you hit "new". That's certainly possible, but also doesn't seem right. I may be old school, but have always tried to follow the best practice not creating things or committing big changes to something without a proper submission… meaning an intentional and confirmed POST request in this case (not a GET request). If you cannot select a content type for that spot (meaning there's only one that can be used), then you go directly to the editing form without the "pick a content type" screen in between. Our screen is probably best termed the "pick a name" screen, or the "confirm you want to create a page" screen. If you are using family settings in ProcessWire, the "type" will not be applicable on this screen as it's already set and not changeable at this point. Though without family settings, then you would be selecting the type too. I would love to do this without hacking the core, obviously. I'm always happy to add new hooks where needed. Just let me know where. Also wanted to mention another alternative. ProcessPageAdd is just a plugin that can be replaced. You could copy those files into /site/modules/ProcessPageAddBetter/ (or start anew if you preferred) and change /processwire/page/add/ to point to your replacement. You could do this by editing the page directly and selecting your new module, or if you could have your new module automate it from its install() method: public function ___install(); $page = $this->pages->get(6); // 6=id of /page/add/ in all PW installs $page->process = $this; $page->save(); } To do this, I'd need hooks immediately before database insert, then again after, I think. These we do have: Pages::saveReady is a hook called immediately before database insert. Pages::saved is called immediately after. Link to comment Share on other sites More sharing options...
deane.barker Posted November 9, 2012 Author Share Posted November 9, 2012 . I may be old school, but have always tried to follow the best practice not creating things or committing big changes to something without a proper submission… meaning an intentional and confirmed POST request in this case (not a GET request). A valid point, but one could ask why you're creating the page from that first step anyway? Why not move the Name the Title to the second page, have the first page template selection only, then create the page after they save from the second step? It seems to me that all the weirdness could be avoided by just consolidating the two screens. Link to comment Share on other sites More sharing options...
ryan Posted November 9, 2012 Share Posted November 9, 2012 Couldn't be consolidated to the second page because you can't have things like Ajax file fields or repeaters (for example) unless a page already exists. The page does not actually exist until you get to that full page editor. Also, "weirdness"? this is the first time I've heard any dislike of the way it works. It all seems pretty natural and logical to me, so I'm confused. But I'm too close to it to comment really. Link to comment Share on other sites More sharing options...
apeisa Posted November 9, 2012 Share Posted November 9, 2012 I agree with Deane - it would streamline the new page process, specially on those cases where template is predefined (like it mostly is). Link to comment Share on other sites More sharing options...
apeisa Posted November 9, 2012 Share Posted November 9, 2012 On the other hand, it gives nice focus on page name (url segment) when creating, but allows it to be "hidden" on settings tab later on... I have not heard any complaints from clients about that 2-step process. Link to comment Share on other sites More sharing options...
deane.barker Posted November 9, 2012 Author Share Posted November 9, 2012 Poor choice of words, sorry. I only meant "weirdness" in relation to what I'm specifically trying to do here. Link to comment Share on other sites More sharing options...
Adam Kiss Posted November 10, 2012 Share Posted November 10, 2012 reading through this, fron the UX standpoint, your best option might be to create admin module, that will be in the main navi, like 'add person'. when you open it, it shows you firstname lastname fields, and when you submit that, a new page is created, with name and title created programatically. for the edit/delete actions, nothing changes (and you seem to have figured those out) 2 Link to comment Share on other sites More sharing options...
thetuningspoon Posted July 31, 2014 Share Posted July 31, 2014 Sorry for dragging up an old thread. Has anything more come of this? I'm with deane.barker-- If the page you're creating has no global fields set/is set to ignore them and there's only one template option available, there should be a way to make it into a one-step process. When pages are being used just as data containers (i.e. for storing images), having to go through that extra screen can get old really fast. Some kind of method of custom auto-generating names would also be hugely valuable. For example, all children of the "gallery" page could auto generate a default name like img001, img002, img003 based on a pattern you give in the parent template's "Family" tab. If no pattern is specified there, you could just use the page ID. This is also where you could add the setting for "Create child pages in one step". Link to comment Share on other sites More sharing options...
adrian Posted August 4, 2014 Share Posted August 4, 2014 @everfreecreative, This has been in the dev branch for a while now: https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=58107 Does that take care of the functionality you are looking for? 2 Link to comment Share on other sites More sharing options...
thetuningspoon Posted August 5, 2014 Share Posted August 5, 2014 Yes, exactly how I thought it should be, too! How the heck did I miss this?!?! Way to go Ryan! EDIT: Just tried it out. Only thing I would add to this is the ability to use any other field (rather than just the title field) as the name, or to just use the page id as the name. I'm not using a title in some of my templates since it doesn't apply. Link to comment Share on other sites More sharing options...
Pavle Posted October 6, 2014 Share Posted October 6, 2014 Hey all, I guess I will just write here instead of starting a new topic. Only thing I would add to this is the ability to use any other field (rather than just the title field) as the name, or to just use the page id as the name. Did anybody manage to implement something like that? More specifically I would need title and name field to be pre-populated when creating a new page ($page->title = $page->parent->title & $page->name = "temp_".$page->title). I was planning to do it via hook in module, but I have no idea which hook would do something like that. Page name would than be renamed based on some field value (which I guess is simply done using "before save" hook). Thank you all for your help! EDIT: OK, it was actually really simple solution. I solved it by using "one-step page add" solution from above, then I used a "saveReady" hook to rename page title and page name. The only problem that remains now is how to check if user changed the title after. In other words: how to check if the title that is present now (before the page save) is the same as the one in the database. $page->field outputs the one from db and I don't know how to access the one from the form that was just typed in. I tried with $input, but it doesn't output anything. Any ideas? EDIT 2: So the answer to my last question (if somebody will need it) is: When attaching something to saveReady hook, one can access form values (on a new page dialog) via: $event->arguments('page')->data['field'] For example to get to title: $event->arguments('page')->data['title'] 2 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