nik

Hi and welcome to the forums! You're definitely on the right track, just a little PHP to be learned I think . I guess you've tried something like this: echo "$page->next->name"; To make it work you need to add some curly braces, like this: echo "{$page->next->name}"; And probably you're actually after url rather than name (as Soma says above, it seems).

@Soma: I've got nothing to add or otherwise contribute here, but just wanted to say what an impressive explanation you've come up with! Good job as always - this time it just felt like a simple 'like' isn't enough.

Yes, looks like it. The method handling 'path' and 'url' in selectors (https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/PageFinder.php#L572) doesn't check which operator was used, but assumes it was '='. At least it should raise an exception if an unsupported operator was used. I think Ryan will spot this from here. There are methods next() and prev() for a page. They only give you one page in each direction (if one exists) but it shouldn't bee too hard to implement what you we're asking for using those. But do consider Ryan's comment in the source: "Be careful with this function when the page has a lot of siblings. It has to load them all, so this function is best avoided at large scale, unless you provide your own already-reduced siblings list (like from pagination).

You can say sort=random, both for database operations ($pages->find/get) and PageArray operations (find/get/sort). See https://github.com/r...Finder.php#L490 and https://github.com/r...Array.php#L681. I tried that "path!=..." selector out and was able to reproduce the problem as described.

Welcome to the forums sw_double! I'll have to dig a bit deeper to find out why that doesn't work. By the looks of it it really should. Meanwhile, this does the trick for you: $items = $page->siblings("template=portfolio-item, sort=random, id!=$page"); Edit: Ah, I see you found the solution yourself already. I'm still interested in the actual cause, will come back later...

Let's try with a couple of pointers and such first. Take a look at site/modules/HelloWorld.module (included with default installation) for an example of an autoload module and hooking methods - example 1 is really close to what you need. As Ryan said, you're aiming for Pages::saveReady with your hook. See http://wiki.processw...Module_Creation for more details on creating modules. This information should be enough to make an autoload module of your own, and have some method there run every time a page is saved. Of course you also need a field for the total price. Create a new field and set its visibility to hidden. Save the field once first to see this option in input tab. Then just add it to your product template. Getting further, you'd probably want to do your magic only for pages with the product template. And sanitize the price and vat before any calculations. You can set fields for the page in your hook like this (and they get saved magically): $page->nameOfYourField = "this is the value"; Now just go and try to create the module. . . . And now that you've tried and got it actually working (right? ), you can see an example of a working module here: https://gist.github.com/4462130. This calculates the area of a box with given width and height on a page with certain template - sounds a bit familiar, doesn't it?

Sorry, I just have to point this out: don't you have the blocks here the wrong way around? Everyone probably gets the point and corrects this automatically though - as you did with the latter examples yourself . Unless they just copy and paste the first snippet and go from there...

Hmm. That skipLabelHeader didn't exists at 2.2.0. So if you got the error message after downgrading back to 2.2.0, there must be traces of the upgrade lurking around somewhere. Clearing cache and probably restarting Apache would still be my best guess though. Just thinking aloud here .

Yes, that's what I meant. Can't help much more right now (on a mobile..), sorry. Clearing the cache has usually been what's needed, for me at least. Especially as you replaced the whole wire directory so it shouldn't be about any file missing or something like that. I hope someone else is able to help you better!

Try deleting site/cache/module* for starters - that may help both ways.

Yes there is, see http://processwire.c...rd/#entry21465. Do you still like it? (Edit: I'm slow...)

A little more OT, but I have to disagree with what you're saying. When using find() the order of sort and limit doesn't matter at all if they're both used at once. The database query would be like '... ORDER BY xyz LIMIT nnn' either way. And if find() was used for an already existing PageArray, this would still hold true - works perfectly both ways (sort is executed first). But, if the sort and limit were done separately, it's a different story (left other selectors out): find('sort=-created, limit=1') equals to find('limit=1, sort=-created') ..but.. find('sort=-created')->find('limit=1') does not equal to (unless there's only one item in the array we're dealing with) find('limit=1')->find('sort=-created')

Thanks Ryan! I may even go and get rid of the little tweak I used to get around this . Actually after trying out some not-so-clean solutions for this I finally came up with a really simple one (which mostly seems to be the case with PW anyway). I had an extra page reference in the template I needed this selector for and then a tiny module to set it to parent whenever the page got saved ($page->fake_parent = $page->parent). This way I was able to use a selector like "fake_parent.title|title*=Something" with PW 2.2. +1 for the unit tests! And once the selectors are covered and some kind of a test suite is up, I'm sure there are other parts of the core that would benefit from a little unit test here and there. Just to make it easier for you to refactor whatever needed as you go on building and improving ProcessWire features and versions. While the implications on most used parts of ProcessWire core are revealed pretty fast, there are these must-work-but-would-not-want-to-touch things like localization and internationalization also. Just to name a couple. I'm also willing to help you out with writing those tests if you'd like. Would offer a helping hand with the whole test suite as well, but I'm not experienced enough with that kind of stuff to get it right at once I'm afraid.

Umm, looks like I never actually reported back, sorry. So, no problems with the latest 22 digit version for me so far. I haven't done any systematic testing though, but it's looking good. I compiled a table of the PHP tests run by me and Teppo if there ever happened to rise a need for the information gathered so far (hope not actually). This still remains somewhat a mystery to me, as there does not seem to be any one common factor involved - among the suspected ones that is. I don't actually think it has anything to do with Suhosin (Patch nor Extension), not alone anyway.

You can check if a viewable child (or more) exists like this: $viewableChildren = false; foreach($page->children() as $child) { if($child->viewable()) { $viewableChildren = true; break; } } if($viewableChildren) { // ... }

Hi totoff, empty() doesn't tell you anything useful for objects, returning always false even for objects with no properties at all (as of PHP 5.0.0). See http://php.net/manual/en/function.empty.php for more details. $pages->find() always returns a PageArray, which is an object although it behaves very much like a plain PHP array. To see if any items were found, you can use count() method like this: if($featurednews->count() > 0) { // ... } Using a PHP function - count($featurednews) - would work just as well.

Based on earlier test results that 22 digit salt should work just fine as there has only been problems with shorter ones so far. I see Ryan already updated this in the dev branch, so I'll do at least some testing later today and report back.

Umm, may I ask why I'm "just" second? And I mean by judging solely based on likes-to-posts ratio as I'm not capable of doing anything more than that.

Thanks Ryan! Now I'm able to pass template changes through (by checking redirectUrl) and not mess them up. Next going to see how to handle new pages and then maybe provide possibility to change the behaviour when saving fields/templates as well. We'll see where I'll end up with this.

I'm not sure I got your question right, but that doesn't seem very unefficient to me. The first two lines could be replaced by this though: $find = $pages->find("has_parent=1134, template=subcategory"); So no need to get the ancestor first but go straight to find any page it's parent or grandparent of. Maybe this was what you were after?

No pro here either, just an overly enthusiastic developer banging his head against a PHP-wall . But I guess you're right adam, that would solve this for any new installation. The simplest approach just has this little drawback of blowing passwords for any existing 2.2.10 installation where Blowfish has already been utilized. We've got a live site running that version but with Blowfish disabled so no harm would be done here. I've understood that Ryan's got his sites using the latest version so there may be some problems ahead there, possibly manageable though. But there might be someone else using the latest dev version as well. So the safest bet would be to find the correct parameters and their values to check for and use Blowfish whenever we know it works with the current salt implementation. But I'm fine with changing the salt to be 22 digits as well. Still that may need some more testing as well.

I was just about to say "that sounds good, go for it". But then I decided to give it one more test, just a quick one. Yeah right, like one of those ever existed in the middle of the night. So now, a couple of hours and a few installed PHP versions later, I'm about to lose my mind. I've tried all the PHP versions I was able to find pre-packaged (for that Ubuntu 10.04) and the only one I got working was the very latest 5.4.9. Both 5.3.6 and 5.3.10 (!) failed for me. Well, these results combined with the previous ones and I was about to say the problem was introduced somewhere between 5.3.10 and 5.3.14. But. A handy tool at http://3v4l.org/ comes in to "rescue" (allows to run a piece of PHP script in 80+ different PHP versions). I ran that script given in my previous post, just to get results like this: After comparing all the results with each other, the only conclusion I'm able to come to is that there actually is no problem with a plain PHP. The problem does exists, but only when there's Suhosin-Patch around. I'm just not able to find out the exact pattern. I was able to test with three different versions of PHP with Suhosin-Patch: 5.3.2 (failed), 5.3.15 (ok), 5.4.9 (ok). So this few hours didn't give that much new information after all . And besides PHP version there's actually another parameter now: Suhosin-Patch version. I did come up with a simple test though. If the next line run from the shell gives a result of "*0", it's run on a problematic combination of PHP and Suhosin: php -r 'echo crypt("test", "$2a$11$12345")."\n";' Then run these to get the version information for comparison: php --version php -r 'phpinfo();' | grep Suhosin Got to go and get some sleep now. I think this will haunt me all night though...

One way is to make the whole thing into a process module. Take a look at Ryan's example (https://github.com/ryancramerdesign/ProcessHello), that's where I got started.

Sorry Joss, I was out of actual buttons, but I implemented something else that might interest you as well. See http://processwire.com/talk/topic/2369-module-pageeditredirects/. Your post reminded me of a much older thread I once read (adam was actually involved with this back then) and there I found another way to accomplish the same kind of functionality. Maybe that could evolve into something useful even.

Edit 2013-01-09: This module is deprecated - see the next gen version here: http://processwire.com/talk/topic/2515-module-aftersaveactions/ - - - After following the discussion on multiple save buttons and default action after page save I decided to give it a try. The result (or an early version of it to beat Soma ) is a module called PageEditRedirects. The module, inspired by this post in particular (and another module by adamkiss), adds four options to choose from when saving a page: stay in editor (default) go to the page list add a new sibling page view the edited page The options are always collapsed and the chosen option is saved into a cookie so that each user's preference will be remembered. Probably should add a checkbox "Remember this setting" (unchecked by default) so that a one-time use of another option doesn't get sticky. Module can be downloaded from https://github.com/n...geEditRedirects and wont be available from the modules directory just yet (because of the required PW 2.3). So, consider the module just an alpha version or a proof of concept as it hasn't been tested nearly at all (need to check it doesn't break Antti's Adminbar for example). Edits: * Added link to an early post on the subject. * Added a little more explanation on what the module does and doesn't do. * Removed the note on needed core changes (Ryan did those already).