ryan

Do you have any other modules installed? PW was checking for a POST with count($_POST), then it didn't see the expected 'submit_save' POST var and threw the message you received. I think this is the way the code has worked since 2.0. So I changed it to just look for 'submit_save' instead (no reason to do both I suppose). My best guess is that $_POST was populated with something for some reason, even though there was no POST. Would be interesting to see a print_r($_POST) to see what was in it. The only thing I can guess is perhaps something from another module?

Pete is right about that approach. Another option is that you can edit /site/config.php and change $config->advanced = true; Following that, when you edit templates, you'll see a 'system' tab that provides several other more advanced options like the 'noMove' option. These are intended primarily for PW core and module development.

Glad to hear it's working after a re-upload. I think it was most likely just that htaccess file… That's the only unix-hidden file in PW.

Looking in the code, the only way you can receive that message is if something is POSTed to ProcessPageAdd that isn't from the ProcessPageAdd form. I went ahead and changed it to check a different way (just in case?), if you want to grab the latest commit, or just this file if you prefer: https://github.com/ryancramerdesign/P21/blob/960742d2c91ec66e7d593926f59a0c9d6f2125a9/wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module

Based on where the majority of our traffic comes from, I think it might be considered a European forum.

Double check that you've got the .htaccess file in your webroot. The favicon.ico messages shouldn't appear in your error log because the .htaccess file prevents them from going to PW. So if there is a favicon.ico message there, it makes me think the .htaccess might be missing or is from an older version of PW?

See the pagesAfterSave function above. If the page was moved then $page->parentPrevious is set. That var holds the old parent, while $page->parent holds the new parent.

Thanks guys, don't give me too much credit or you'll be disappointed in this thing because it was put together quickly and there really isn't much to it. But I figure it at least gives us a good starting point.

Here are examples of hooks you asked about: <?php public function init() { $this->pages->addHookBefore('save', $this, 'pagesBeforeSave'); $this->pages->addHookAfter('save', $this, 'pagesAfterSave'); $this->pages->addHookAfter('delete', $this, 'pagesAfterDelete'); $this->pages->addHookAfter('trash', $this, 'pagesAfterTrash'); $this->pages->addHookAfter('restore', $this, 'pagesAfterRestore'); } public function pagesBeforeSave(HookEvent $event) { $page = $event->arguments[0]; if(!$page->id) { // set your own var name to check after page saved $page->this_is_new = true; // do anything else you want here } else { // page is an existing page } } public function pagesAfterSave(HookEvent $event) { $page = $event->arguments[0]; if($page->this_is_new) { // check the var you set before to determine if it's new // page now has an ID, so do something with it if you want } if($page->parentPrevious) { // page was moved. $page->parent is new parent // and $page->parentPrevious is old parent } } public function pagesAfterDelete(HookEvent $event) { $page = $event->arguments[0]; if($page->is(Page::statusDeleted)) { // page was deleted } } public function pagesAfterTrash(HookEvent $event) { $page = $event->arguments[0]; // page was moved to the trash } public function pagesAfterRestore(HookEvent $event) { $page = $event->arguments[0]; // page was moved out of the trash }

Sounds like a lot to keep track of. But I think you'll be able to do most (or all) of it by hooking into: $pages->save() $pages->delete() $pages->trash() $pages->restore() If you only want to hook these things in the interactive PageEdit, as opposed to all of the API, then you'll want your hooks to check the value of wire('process') (or $this->process) and confirm that it is 'ProcessPageEdit'. Let me know if you find you need other hooks that we don't already have. In PW, making a function hookable is as easy as prepending 3 underscores to the beginning of it. So I've not attempted to add all possible hooks in the system, instead taking the approach of adding new core hooks as needs arise. Sounds great! You've really thought this through. I like all that I hear. In PW, you can make a new API var (available to all templates and modules) by calling: Wire::setFuel('api_var_name', $your_api_var); Thanks, looking forward to it!

I was originally thinking maybe you had a version prior to 5.2.4 because I had the same problem on a PHP version older than that (one of the reasons why PW doesn't support versions before 5.2.4). It doesn't sound like that's the case here... A couple more things to try: 1. Look in /site/assets/logs/errors.txt to see if there is anything in there. 2. Try installing a fresh copy of PW under some subdirectory, just to see what the installer says. The installer might find an issue that wouldn't be apparent when migrating an existing site.

Attached is a module that gives you page level access control for view access in PW 2.1. It's fairly basic, but gets the job done and it's something to at least start from. I've tested it to make sure everything works, but not exhaustively, so let me know if you run into any issues with it. To install 1. Copy the attached file (CustomPageRoles.module) to /site/modules/ 2. Click 'Check for new modules' in Setup > Modules. 3. Click the install button for 'Custom Page Roles'. It will automatically add a field called 'page_roles' to your fields list. Add this field to any templates that you want to have page-level access control. Now when you edit a page using a template that has this field, you'll have checkboxes for roles that you can choose to define access from. When at least one role is checked, the page has access control authority for 'view' permission, rather than the template. When no roles are checked, then it will check the parent page to see if it has a page_roles field and delegate control to it. That parent's page_roles field is used in the same manner. As a result, you can inherit up (or down) the tree as long as the parents have page_roles fields. Authority will be given to whatever parent ultimately defines access (by having at least one role checked). If a page has a page_roles field with nothing selected, and it's parent doesn't have a page_roles field, then access inheritance stops and access control is deferred to the template. As an extra security measure, I've also set it up so that a page's template has to allow 'view' access in order for a page using it to inherit access from a parent page. Though I'm not sure if I should keep it this way... But here's the thinking: page level access control is a little bit dangerous in that one change can affect a lot of children (grandchildren, etc.), so that extra security is just so that the superuser exercise additional control where they deem necessary. This is similar to access control in PW 2.0 except that it's a little simpler (and perhaps less powerful) in that all the roles are inherited as a group rather than individually. Though this also means less ambiguity, which is a good thing. But ultimately this module is just a starting point and you all may want to suggest improvements or take it further. Caveats The main caveat here is that this does not affect results returned from $pages->find(), $page->children(), etc. Those are purely controlled at the template level. Here's two scenarios where that could affect you: 1. If access is allowed by your template, but not by your page, your page may still appear in search results and API functions like $page->find() and $page->children(). That doesn't mean the user can view the page, only that it may appear in searches. If you don't want that to happen, you'd have to take the same approach that you did in PW 2.0. When outputting a list of pages, skip over any where $page->viewable() returns false. 2. I think this will be an uncommon situation, but if you have guest access disabled in a template, but enabled on the page, the page is not going to show up in API functions that return PageArray. To make it show up, you'd have to add: "check_access=0" to your selector, like this: $page->children("check_access=0"). --- Edit: re-uploaded CustomPagesRoles.module file to remove two lines of unnecessary code and incorrect summary. No significant functional changes though, so you don't need to re-download if you don't want to. CustomPageRoles.module

Looking great Soma! The site really shows your mom's artwork well, and she is an amazing artist! Let me know when it's at the final URL so I can update our directory too.

Nice job and beautiful site!

Actually I had forgotten that we had that configuration option there–good find. Filter fields is always active now. I need to remove that config option. Thanks, Ryan

Okay latest commit fixes this. All I needed to do is add "!important" to the end of a style.

Hey guys, I've added the $pages->clone() function to the API and you'll see it in the latest commit (or the one before it). I've tested on a few pages with files and children and so far so good. There's a lot that it has to do, so this is not something I'd use to clone a 1000 page tree, but it should be fine recursively cloning most stuff. I'd like to do more testing but have run out of time for today, and opted to go ahead and push it to the source tonight so that I could get it to you sooner rather than later. I think it's pretty solid, but just to be safe, I recommend considering that function unstable until we've run it through a lot more scenarios. Here's how to use it: <?php // clone a page or tree of pages $copy = $pages->clone($page); // clone a page or tree of pages, and give it a new parent $copy = $pages->clone($page, $newParent); The $copy that is returned is already in the database, ready to go, and does not need to be saved again. Please let me know if you run into any issues with it. Don't use in a production environment until we've had a few more people test it. Thanks, Ryan

The back button might not be a bad way to retain that state, and I think it should be possible to do live updates to the URL as they are clicking on pages in the PageList in order to remember where they were. But back buttons in a CMS are usually a behavior you want to steer people away from. You can possibly back up to previous versions of content and accidentally save, overwriting newer stuff. Though I can't say as though I've ever run into that problem myself. But as for remembering the state in other situations, I'm a little afraid to make assumptions about where the user wants to be. It seems okay in breadcrumbs, but would be a big assumption make that they want to return to the same spot whenever they click 'pages'? Though if one wants to configure that as the behavior (perhaps in PageList module settings), that's always a possibility.

If I understand what you are asking correctly, it wouldn't be hard to implement. ProcessWire already has a way to open any branch in the tree just by specifying the page's ID in the URL to the PageList with "?open=123" where 123 is the ID number of the page. i.e. /processwire/page/list/?open=123. The only place where this doesn't currently work is with pages that are deep in levels of pagination. It would be relatively easy to return to any state by saving it in a cookie. What are the scenarios where you'd want to use this?

Sorry I didn't read high up enough on the page before and missed this: I understand what you are saying here and these are good points. But I want to clarify that the file is a component of a template. They are part of the same thing. It's like a car and it's engine. When we are on the file system, it's assumed we are dealing with files. If we open the hood on the car it's assumed we're going to find an engine… yet we're still talking about a car. When you are working with template files, you are working with the template's representation on the file system. There is no other representation of a template on the file system. Given that, I don't think it matters whether we call it ./templates/, /files-for-templates/ or ./template-files/, so I'll choose whatever is easiest to type. In that URL on processwire.com, I think it's more just a matter of trying to make URLs are short as possible. Template-files would technically be a more accurate fit in that URL. Though everything you do with the API takes place in files, and /api/templates/ at least provides context to the term. But I agree that template-files would have been a better URL name here. But I'm also not sure it matters enough to change it (already been there for a long time).

Awesome, I look forward to checking it out. I actually haven't had any music playing here for months, so will enjoy this. Thanks.

Different CMSs use different terminology. My opinion is that I'm not comfortable letting another CMS define our terminology. I think we have to stick with the actual definitions of terms. So here is the dictionary: I can't think of any term that better describes what Templates are in ProcessWire: Oops, not that one, sorry This one: ...and... This is what Templates are in PW. A template in PW also has these components: - fields - file - access - urls - cache One large component of a template in PW is it's file. I think the term for that naturally should be: "template file". It could also be "output file", but a template file doesn't necessarily have to produce output so I don't want to use a term with any built-in limitations. Of course, the term "template file" also fits with the definitions above when qualified with "file". A template file also has a natural dependency of the fields used by the page (template) it is processing. The two are interconnected and part of the same thing. I think that changing the terminology or splitting these things up is unnecessary complexity. Some people may want to split them on occasion for technical reasons (and PW will let you in advanced mode), but I want to always target simplicity first. My opinion is that terminology like "template and "template file" fit the definitions and relate to each other in the appropriate manner. But I'll also qualify that by saying that it's also what I'm used to, and I think we all naturally prefer what we're used to.

No actually I think you are doing a good job of describing it, especially with the examples you just posted. You have complex access control needs and I think it would be difficult to describe in any language. Wow. This is all in one site? Stepping outside UA for a moment, I do wonder about possible efficiency, security and diversification benefits in having each association run off a separate database (smaller databases, less data, smaller indexes, faster execution, less chance of a problem in one affecting others). I'm only taking about separate databases, but sharing the code. This is more of an inquiry–how do you diversify these large scale needs? Stepping back into UA, I think that I understand now. It sounds like this is likely a complex UA setup regardless of where its implemented. If you were doing page-level UA, wouldn't you still need just as many (or potentially more?) access control points? I can see why you have so many templates in this scenario. But the main reason for that seems to be that there are 200 sites bundled into 1? If these were independent sites, they would have 2 access control points for teams, or 6 access control points for associations? That would seem much more manageable and more consistent with the intentions behind the current system. While it may be possible to implement, PW was admittedly not designed for managing the access control of 200 sites in one database (sounds like we need template pagination!). But I do think we can open the hood and add some custom modifications to make it sing in your situation. I would suggest that because your needs are pretty unique, we should collaborate on custom building an access control system specific to the needs of your company. I think we can make this a lot simpler just by focusing on this specific case with custom access control modules. I also wonder about abstracting the access control out of the site(s) completely, moving it to a shared web service (perhaps powered by PW) so that you could run the sites independently on separate databases, but allow the access control managers to control it in one place, just like the developers would edit the templates in one place. That way you could still get the efficiency and diversification benefits of separate databases. These are just ideas from an outsider that knows very little about the reality and scope of the needs there.

Fixed. I went ahead and made those pages non-searchable. I will wait till Jim finishes them.

In that case, with the 2.0 version, I would instruct them to use the existing link tool and paste in the file's URL as the href. Grabbing that file URL is as simple as right clicking on the filename in admin and selecting 'copy link'. This is how I always did it before adding the file selection to the link box in 2.1.