ryan
-
Posts
16,772 -
Joined
-
Last visited
-
Days Won
1,531
Everything posted by ryan
-
That's right, sorry I meant addHookAfter (trying to type too fast). If you need to show on the live end of things too, then I think you are right about the best method to use. I would probably change the regexp to this (add the "i" at the end), just in case someone is using uppercase tags for some reason: $out = preg_replace('/(<body[^>]*>)/i', '$1' . $code, $out);
-
Try running this script on the same server and browser and let me know what you get: <pre> <?php if(count($_POST)) print_r($_POST); else echo "POST is empty"; Just want to make sure you don't have some spyware or something behind the scenes trying to experiment with POST vars.
-
You could change it to an addPageAfter hook and then just prepend it to the output, i.e. <?php $out = $event->return; $code = '<p>Site in maintenance mode</p>'; $out = preg_replace('/(<body[^>]*>)/', '$1' . $code, $out); $event->return = $out; PW's <body> tag doesn't actually have any attributes, so you could also do this (below) but the above is a little safer just in case we add attributes in the future (or somebody else's theme does): $body = str_replace('<body>', '<body>' . $code, $body); Another option is to use JS in your hook. In this case, you could use the Page::render hook, or another if you preferred. $this->config->scripts->add($this->config->urls->YourModuleClassName . 'your-file.js'); Your JS file would have this: $(document).ready(function() { $("body").prepend("<p>Site in maintenance mode</p>"); }); It's perfectly fine to use a JS-only solution in PW admin because PW admin requires JS.
-
Module: Languages (multi language content management)
ryan replied to Oliver's topic in Modules/Plugins
That's correct. While there isn't an attr() method on the Template object, you could set it from the API like this: $template->noMove = 1; or $template->set('noMove', 1); (the first example routes through the set() method behind the scenes) -
That's not the intended behavior. Some of my code is still adjusting to jQuery 1.6. Thanks for finding it. Fixed in the latest commit.
-
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?
-
Module: Languages (multi language content management)
ryan replied to Oliver's topic in Modules/Plugins
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
-
Module: Languages (multi language content management)
ryan replied to Oliver's topic in Modules/Plugins
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?
-
Module: Languages (multi language content management)
ryan replied to Oliver's topic in Modules/Plugins
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.
-
Module: Languages (multi language content management)
ryan replied to Oliver's topic in Modules/Plugins
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 } -
Module: Languages (multi language content management)
ryan replied to Oliver's topic in Modules/Plugins
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.
-
Module: Languages (multi language content management)
ryan replied to Oliver's topic in Modules/Plugins
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).
