ryan

Honestly it's probably not going to matter much here, so I'd say go with whatever is more readable to you. But since you asked: technically, if you can get something done with just one find/get operation rather than two, that's going to have an edge. Meaning, your single $pages->find("template=article,author=john"); is probably going to be the most efficient. But not likely in a way that's going to be measurable. Something to note is that both $pages->get() and $page->children() (and pretty much any method that returns pages from the DB) are simply front-end's to $pages->find() with certain assumptions placed on top of them. Not much of a performance hit, but you are right that it's not as efficient as just letting it load at the original URL. That's because behind-the-scenes your homepage is first being rendered (or at least its template is being called), and then another page is being rendered from it. If you don't want any compromises at all, even if small, then you could instead make your homepage template perform a $session->redirect($article->url); to the actual article page URL, and that way your homepage URL segment code would just be handling the requests that come in externally. Your local URLs would already be pointing to the /articles/article-url/. As for whether you are thinking too much, maybe. We're talking about micro optimization here. If you have a preference for using the /article-url/ URLs off the root, then that should carry more weight than the micro optimization. And if you are rendering pages off the root like that, make sure you are using <link rel='canonical'> tags in your document head so that the search engines don't think you've got duplicate content.

Like mentioned in last week's post, this week was focused on covering remaining GitHub issue reports and pull requests in preparation for the 3.0 and 2.8 master version releases. In total we covered close to a dozen issues and around ten pull requests this week, so you'll find lots of updates in today's versions (3.0.29 and 2.8.29). In addition, we've also got a section in this post for those that have inquired about ProcessWire site development help. https://processwire.com/blog/posts/pw-3.0.29/

The latest post includes coverage of weekly updates to the ProcessWire core, as well as a look at how to create your own custom utility hook functions… https://processwire.com/blog/posts/pw-3.0.28/

This week the core continued to be upgraded for more Fieldtype features like pagination support. We also released a new version of ProFields Table (v14). This post also looks at a new SmashingMagazine.com tutorial and more on the 3.x release timing. https://processwire.com/blog/posts/3.0.27/

With support for paginated Fieldtypes, ProcessWire’s scalability has moved to the next level. Not sure what this means? Don’t worry, this post has a screencast that makes it clear. We’ve also got some other nice upgrade for ProFields Table. https://processwire.com/blog/posts/fieldtype-pagination/

This week we've got a pretty major upgrade to our page finding selectors that we think you will find useful in a lot of cases! Now you can accomplish much more with less, and this really brings our selectors to the next level. https://processwire.com/blog/posts/pw-3.0.25/

Great, glad you got it figured out! You must have literally fixed it between the time I reloaded the page, and clicked "view source", since one tab had the issue and the other didn't.

No, ProCache only saves the cache after all the code in your template has been executed, and right before ProcessWire shuts down. Perhaps the old cache files are still present and the cache just needs to be cleared? Or perhaps the issue isn't the caching at all, and we were just seeing a side effect in the cache (this is what I think is most likely the case). Also your, $config->maxUrlSegments setting really does not matter too much, so long as validation of the $input->urlSegmentStr is working property. It sounds like the bogus URL pages are throwing 404s, so that's good. So now what you need to look for is what's generating the bogus URLs in the first place. They are appearing in the code, so they are coming from somewhere. It looks like they aren't originating from URL segments at all–that's just the result, but apparently not the source. So we need to look deeper. Here's something interesting. If I view the page at: http://ukmoths.org.uk/thumbnails/gracillariidae/ and hover a pagination link at the bottom, like "4", I can see the bogus URL. Yet if I view (not inspect) the source code, the links are clean. What that points to is that something from the Javascript side is manipulating the links. However, I can't confirm it because all the links are now clean, can't get any more bogus links, almost like you found and fixed something while I was viewing it. But if you are still seeing the issue, try viewing the same page with javascript disabled. If you can confirm it, start zooming in on the different JS parts, like perhaps the email obfuscation JS is still getting called somehow or another?

Ian, I'm not sure what components of the URL correspond to each URL segment, but it looks to me like possibly the issue is urlSegment2 not urlSegment1. You've got lots of good URLs to test with there from that screenshot, so you'll want to make sure that when you access the page at a URL like that, you get a 404. That will solve the issue. Also, if you are only needing 1 level of URL segments, I would suggest doing your comparisons against $input->urlSegmentStr rather than $input->urlSegment1. For instance: $fam = $input->urlSegmentStr; if(strlen($fam)) { if(!isValidFamily($fam)) throw new Wire404Exception(); $specieslist = $pages->find("template=species, limit=12, fam=$fam"); if(!count($specieslist)) throw new Wire404Exception(); $fam = $sanitizer->entities($fam); $metatitle = "British Moths | Thumbnail List by Family | $fam"; $title = "Families: $fam"; } Using $input->urlSegmentStr is better because it is inclusive of all URL segments. So if there are extra URL segments packed on to the end (like the bogus ones we see after the family names) then this will catch it, without you having to check $input->urlSegment2 separately. For example, the $input->urlSegmentStr of the page accessed at /thumbnails/gracillariidae/ would simply be "gracillariidae". Whereas if accessed at /thumbnails/gracillariidae/some-bongus-junk, then the urlSegmentStr would be "gracillariidae/some-bogus-junk", which presumably your isValidFamily() function would be able to exclude.

@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.