ryan

@Robin S Have a look in the PageTraversal class (/wire/core/PageTraversal.php), and the _next() method. It's all in there. The gist of it is that it works roughly the same as before, with one big difference: rather than loading all the sibling pages (Page objects), it loads all the IDs instead (integers), in order. It doesn't always have to load them all either, just enough to determine relative positions. Once its found the needed ID(s), it converts them to Page object(s). It also involved upgrades to the PageFinder class so that it could support startAfterID and stopBeforeID options. If you look at the end of the PageTraversal class, you'll see an earlier implementation that I worked with for a couple of days before coming across a couple of situations I just could not get it to work in (and became clear it never could), so ultimately had to abandon it. However, since it relies on how sibling pages are sorted (rather than relative positions), it doesn't have to load near as many, making it potentially faster (and more memory efficient) if there are thousands or millions of siblings. Though in my own testing, it was always slower until the scale got really large. Not to mention, it's a whole lot more complex, and can't cover all situations. But I'm leaving it commented out in there for a little while (for reference) since so much work went into it before finding a much simpler solution.

This week updates were focused on covering GitHub issue reports and feature requests, plus some great new performance improvements to our page traversal methods… https://processwire.com/blog/posts/pw-3.0.24/

Ian, first thing to check is how you are using URL segments. It looks like pages like http://ukmoths.org.uk/thumbnails/crambidae/ allow URL segments. If you don't need URL segments, disable them. If you do need them, then make sure you validate the URL segments that come in and throw a 404 if you get something invalid. For example: if(strlen($input->urlSegmentStr)) { // one or more URL segments are specified if($input->urlSegmentStr == 'photos') { // display photos } else { // invalid throw new Wire404Exception(); } } Second thing I would look at is the email obfuscation module you have installed. I notice the code it is adding (near the bottom of the source) appears to be using the same encoding that appears in those URLs, so I'm wondering if that might be adding it? Try uninstalling the email obfuscation module at least temporarily to see if it makes any difference.

Thanks. All sites that I currently work on are multi-language (other than this one we are at now). I'm not sure I understand what you mean, as the core doesn't remove or rename anything. When the SystemUpdater detects a version change, it clears the modules cache (in the database), but that's about it. Make sure when you upgrade that you replace your entire /wire/ directory (renaming or removing the old one first).

This week we have a few nice tweaks for those using multi-language support and translation tools in ProcessWire. Plus improvements to the 2.8.x branch, and a new feature for repeaters. https://processwire.com/blog/posts/pw-3.0.23/

What you've got above is an AND condition, which I think is what you want. You could also do this if preferred: id!=[title|job_body%=word_to_exclude]

Macrura, great–glad that was it! I've updated the core Field.php file so that this should no longer be an issue: https://github.com/ryancramerdesign/ProcessWire/commit/c0b30dbb24d30845d98ab1c9d103bbead1a6e629 Still a good idea to define defaults for your module though. If you don't, there's a good chance the module will not work if someone creates a field and neglects to change any settings (and thus never saves any config data).

If this is what you already have today, then I wouldn't go changing it unless/until you need to accommodate the issue mentioned in the link. If you are going to be using a CDN with ProcessWire, chances are you'll be doing it with ProCache, where this would not be an issue either.

Macrura, looking in InputfieldSelectize.module, I think the issue might potentially be that there are no default values established for the configuration properties. For instance, there is no $this->set('itemDataArray', array()); in the __construct() method. Though if something was working before, and stopped working after this upgrade, then I'd rather continue making it work than have existing modules have to make changes. I'm wondering if this change might be the culprit? Can you try changing it back to the previous setting to see if it makes any difference in your case? https://github.com/ryancramerdesign/ProcessWire/commit/132ea079f79c574dd39a4a7ca37bd852259e217a#diff-581dc8ba34896b025170325efb07ec90L789 If this is the issue (?), I can think of some other ways to approach this that should resolve it. If that's not the issue, please let me know too and I can continue hunting for it.

This week we have some nice optimizations and enhancements for the core, as well as some great upgrades in the forums! Our Inputfield forms (including page editor) got a whole lot faster, and our Password field got a ton of nice enhancements. These updates are all available in version 2.8.22 as well. https://processwire.com/blog/posts/upgrades-optimizations-pw-3.0.22/

We've got some great updates for you this week, especially for those still running ProcessWire 2.x. ProcessWire 3.x also got a lot more stable this week. In fact, this week ProcessWire 2.x and 3.x got a lot closer! https://processwire.com/blog/posts/processwire-3.0.21-and-2.8.21/

Working through GitHub issue reports was the focus of this week, and it looks like we've got one more week to go in working through the current queue. There have not been any major bugs in 3.x, so things are looking more and more stable. Most updates in this weeks version (3.0.20) are about fixing minor bugs and various cosmetic things. There's nothing particularly exciting to report in this version other than that. But working towards a fully stable 3.x master version is itself an exciting thing. So rather than focus on the small tweaks and fixes from this week, lets backtrack and review all that's new in 3.x relative to the current 2.7 master version… https://processwire.com/blog/posts/review-of-processwire-3.x-so-far/

All the language sites should now be up too. i.e. de.processwire.com and so on. wiki.processwire.com didn't survive the server change. Somehow its database had grown to multiple gigabytes, and it appears that it may have been hacked or something. I've lost trust in MediaWiki for our use. Since everything on there is pretty well out of date at this point, we opted not to copy that over to the new server. We could spend days trying to figure out why a small wiki had a 3.5 gigabyte database, so I figured we were better off without it.

@mikeuk Don't worry you are doing fine, don't take anything too seriously. We're all friends here and occasionally like to hit each other with the zen stick, but it's always friendly. The demo site is filling multiple shoes. Sometimes people ask where they can take a look at a Pro module, in which case I'll install it on that demo site since it's already all setup with guest admin logins and such. But LostKobrakai is right that ProCache is disabled as soon as you are logged in, so it's really only there as a demo of the configuration screen. Though admittedly, I do like having it installed there just because for whatever reason people like to scrape that entire site regularly, so ProCache lets them do it more quickly, without consuming too much server resources. I suppose that doesn't matter much now that we're on this new server which has a ton more resources than before.

This week our focus was on the server side of things rather than on the code side. Sometimes you've got to open the hood and change the oil in order to keep things running smoothly. But rather than just changing the oil, we opted to replace the entire car, moving from our compact family sedan to a turbocharged supercar, so to speak. Basically, we've had some major server upgrades this week! This post covers them in detail: https://processwire.com/blog/posts/web-hosting-changes-and-server-upgrades/

There are still a few little things to work out, but we're mostly there. The biggest one I'm aware of at the moment is that forums have no outbound email. It turns out we're required to use an external SMTP server in this case, so working on setting that up. @kongondo I've been messing around with email settings on the modules site this last week, trying to get it working with Mailgun, and decided to just wrap it up once everything was transferred. Outbound email should start working everywhere again hopefully by tomorrow.

All switched! Please let me know if anyone runs into any issues. The new server is quite a bit more powerful than the previous, so hoping you might notice a speed difference too–I sure do.

Just wanted to let you guys know that we're moving all of the ProcessWire sites to a new web host today around 12pm (noon), EST. Our new dedicated server is from IBM/Softlayer, and this is going to be a really great upgrade for us. I'll cover more in this week's blog post, but wanted to give you a heads up that things will be switching today and there may be a brief period of down time. I may take the forums down for a bit when the change is taking place so that we don't have messages getting posted on one server and not another while the DNS updates.

ProcessWire 3.0.19 lets you work with thousands of pages at once, with a new $pages->findMany() API method! https://processwire.com/blog/posts/find-and-iterate-many-pages-at-once/

Version 3.0.18 continues from last week, making major upgrades to our images field. This week we got into some of the finer details, and we've got plenty for you to look at here, as well as a screencast (at the end) to demonstrate it all. https://processwire.com/blog/posts/more-images-upgrades/

Thanks to Renobird and LostKobrakai, ProcessWire’s images field has been re-designed and redeveloped with a lot of great new features we think you’ll love! This new images field is available for use now in ProcessWire 3.0.17. The linked blog post covers it in detail. There’s also a screencast at the end that shows you the new images field in action. https://processwire.com/blog/posts/major-images-field-upgrade/

There's no difference in how you would use $session, $input, or any API variable or any PHP superglobal ($_GET, $_POST, etc). These have nothing to do with namespace. If you must disable the template compiler, edit your /site/config.php and add $config->templateCompile = false; to it. That will prevent any of your template files from getting compiled. As for compiling modules: At this time I wouldn't recommend disabling the module compiler, otherwise almost no 3rd party modules will work. That's because there are few if any PW3-specific modules at present. If you come across a module that isn't working after being compiled, let me know about it so I can investigate it. When it comes to template files (and you've disabled the template compiler): you don't need to add a namespace to all of them. You only need to add it to those that are calling ProcessWire specific functions like the wire() function, or those that are referring to ProcessWire constants or classes directly. Things like this: $foo = new PageArray(); $date = wireDate('Ymd'); $page->addStatus(Page::statusUnpublished); The parts in bold above are those that are referring to things in the ProcessWire namespace. Adding "namespace ProcessWire;" to the top of the file makes it simple, that's all you'd have to do. If you didn't want to do that, you could also just update a wire() function call to be like this: $date = \ProcessWire\wireDate('Ymd'); Or you could just enable the template compiler, which will do this for you. However, maybe you aren't using things like the wireDate() or wire() functions and maybe you aren't referring to things like Page::statusUnpublished. If that's the case, you can skip adding a namespace at all, and likewise don't need the compiler. ProcessWire's API variables like $pages and $input and $session and all of that are going to be present either way. These have nothing to do with namespace.

Last week I mentioned we'd be continuing the documentation updates into this week and that's exactly what we did. All in all, these documentation updates involved 46 files and 5264 additions, so far. Read more about it in this weeks' blog post: https://processwire.com/blog/posts/processwire-3.0.16-continues-expanding-documentation-and-more/

I actually don't think this is a matter of file paths. That error points to one file (like _func.php) having a namespace, and another file (like main.php) not having a namespace (or not referring to the function in the namespace that it exists). If you are letting PW decide whether to compile a file based on whether it has a namespace or not, then you've got to take those same considerations for any files it might include(). A file that doesn't get compiled isn't going to have files include()'d from it compiled either. So it sounds like you probably do have a namespace defined in your _func.php file, but not in your main.php file (or the opposite). For your case, since you are adding a namespace to the to of all your .php files, I'd suggest disabling the compiler by setting $config->templateCompile=false; in your /site/config.php.

I'm not positive this is the solution to the exact issue you are seeing, but I think there's definitely an issue with the include() statements being relative... so the question becomes, relative to what? The screenshot shows on /views/layout/ directory off of the installation root, and another off of the /site/templates/ directory, so I am also confused. The _done.php file appears to be in the /site/templates/views/ directory, but it's using include statements like this that don't specify the starting point: include("views/layout/head.inc"); The problem with the above is that no starting point means it's off to being looked for in all of PHP's include paths. If you want the starting point to be from the current directory, then you'd want to make it "./views/layout/head.inc". However, that wouldn't seem to be right here, since _done.php is already in the "views" directory (rather than the /site/templates/ directory). So it seems like it should instead be this: include("./layout/head.inc"); I'm still a little confused about there being multiple /views/layout/ directories (if I understood that correctly), so it may be worthwhile to be even more specific, like specifying if you want the one that's off of $config->paths->root, or the one off of $config->paths->templates. For example, include($config->paths->templates . "views/layout/head.inc");