ryan

Last week we called it a soft launch, but this week we'll say ProcessWire 3 is now released and considered our new master, version 3.0.35. This post is a changelog of sorts, where we will cover all that's new in ProcessWire 3! https://processwire.com/blog/posts/pw3-changelog/

This is a good reminder for me. There's not enough time in a week (since I got back in town) and there's plenty of little details I still have to attend to, which is why I thought calling it a soft launch was better. This will definitely be added though. You are completely right here of course. I have updated the blog post to add that as well. I agree with this. Composer is pretty awesome and all, but it's not every day that I have a use for it. The work I do rarely requires anything outside of what is already in the PW core. This is likely common among web developers that build sites in PW or some other system that already provides the majority of what you will need. Sephiroth's comment is true when you step outside of this context though, into the wider development world of PHP. With version 3.0 we're hoping to bring more of that world into PW's audience. So even though most of our current audience likely doesn't use/need Composer for many of the sites they develop, my hope is that will change as more people relying on Composer begin to use ProcessWire. Also depending on the site/app, the PW core/modules can't always accommodate every need, so I expect people will very likely increase their use of Composer when the needs for something more arise.

First off, a big thanks to Jonathan Lahijani and Benjamin Milde for taking over the last two weeks of blog posts while I was traveling. They did an awesome job. If you haven't yet read Jonathan's CMS Critic case study or Benjamin's Migrations module introduction, be sure to check them out. This week we started using our new GitHub organization repository to soft launch version 3.0. ProcessWire 3.0 now appears on packagist as well (installable via Composer). We’ve got several other updates for you as well! https://processwire.com/blog/posts/hello-pw3/

This week's blog post is written by Jonathan Lahijani where he writes about the works he's done with CMS Critic: Read the blog post at: http://processwire.com/blog/posts/cms-critic-powered-by-processwire-again-case-study/

This week we’ve loaded up our new ProcessWire repository with the latest 3.x version and we have some more details on that, as well as the official 3.x release date. We’ve also got a recipe you might find useful here as well. https://processwire.com/blog/posts/pw-3.0.33/

Beautiful site, great work Tom! Would you mind adding this one to our sites directory? https://processwire.com/about/sites/submit/

In this post we take a look at the latest core updates and go into detail about how we might handle the release of ProcessWire 3.0 and 2.8. https://processwire.com/blog/posts/pw-3.0.32/

Thanks Ivan, I really appreciate it! You give me way too much credit and are too kind, but such a heartfelt message still leaves me speechless, so thank you again. I don't think I want any kind of luxury car! I'll be honest, while I was sad to give the car back, I was also glad to because it's just plain stressful. There's no problem if someone dents my car or something gets scratched, etc., but borrowing such a fancy car makes you always worried about where you park. If a bird poops on it you have to clean it right off, and so on and so forth. All these things I never worry about, but became apparent when I had to be responsible for such an object for 2 days. I imagine a lot of stress comes with owning something like that. I'm sure to many it's worth it, but still, glad I don't have to think about that kind of stuff every day. If I were to ever own a car like this, I'd buy it after it's already many years old, inexpensive, and has the battle scars to show it. \

No, sadly I don't own a Tesla Model S. Instead I own a 1994 Mazda. But with getting ProcessWire 3.x ready to release, I didn't have a lot to write about this week. So figured, why not chat about something else I'm passionate about (this is a blog after all). Last weekend, I got to pretend that I owned a brand new 2016 Tesla Model S (P90D) for two days and a couple hundred miles. I was so inspired by it, I figured why not write something. We'll even attempt to draw some parallels with ProcessWire. This post also covers updates to several 1st party modules. https://processwire.com/blog/posts/tesla-model-s/

For the modals, after line 352 of PageFrontEdit.js there is setBusy(false); Try adding this right before or after that line: t.trigger('pwreloaded'); I think that will work. But another route is that when the modal window closes a 'pw-modal-closed' is triggered, and that can be captured. That line 352 is within such an event handler, which may serve as a potential implementation example.

Make sure you've got the JS console in Chrome open or something, so that cached files aren't a factor. I'm trying to write about this without being at my computer where I can test it, so take these more as pointers rather than exact code. But you might need to expand that event handler to something like this: $(document).on('pwreloaded', '.pw-edit-orig', function() { // ... }); The front-edit editor uses wrappers <div class='pw-edit-orig'> and <div class='pw-edit-copy'> where "orig" means the original container, and "copy" means the copy for editing.

Alex, an idea here, but I've not tried it yet. If you find it works, I can update our PageFrontEdit.js in a similar manner to trigger the events mentioned below. What's needed is an event triggered that you could monitor and then re-initialize your carousel. First you'd need to update the /wire/modules/Page/PageFrontEdit/PageFrontEdit.js file Starting at line 283, you'll see this: copy.hide(); orig.show(); Update that to this: copy.hide().trigger('pwreloaded'); orig.show().trigger('pwreloaded'); Then in your own JS, monitor the event and re-init your carousel when it occurs. Something like this: $(document).on('pwreloaded', function() { // whatever your carousel init code is, for example: $(this).find('.my-carousel').carousel(); }); Let me know if something like this provides what you are looking for?

This week work continued on preparing 3.x (and 2.8.x) for release. One of the features of 3.x that we'd not yet covered in much detail was the multi-instance support. So the primary focus this week was in making sure we clarified and simplified some things in that respect. This post covers all the details. In addition we've also got some $session updates that we think you'll like! https://processwire.com/blog/posts/multi-instance-pw3/

Some autoload modules establish API variables, like ProCache ($procache) and FormBuilder ($forms). But the wire() method really doesn't have anything to do with modules at all (other than that you can retrieve the $modules API var from it). So continue using $modules->get() to retrieve your modules, and avoid stuffing modules into API vars unless it's something the module itself intends. However, anytime you find the ability to establish your own API vars useful, there's certainly no harm in using it. Just keep in mind that var will remain in scope for the entire request.

Wire::setFuel() is a deprecated method, so don't bother using it. But the purpose of it was to set an API variable. The recommend way to set an API variable now is using the $this->wire() method (available on any Wire derived object). // Set a 'hello' API variable $this->wire('hello', 'Hello World!'); // If outside an object (like in template file) you might do this instead $wire->wire('hello', 'Hello World!'); // If you want to lock it (prevent changes) specify TRUE as last argument $this->wire('hello', 'Hello World!', true); Once an API variable is set, it works the same as any other API variable in PW. It can be retrieved like this: echo $this->wire('hello'); // in object echo $this->hello; // in object echo wire('hello'); // anywhere echo $wire->wire('hello'); // in template file echo $wire->hello; // in template file echo $hello; // in template file All of the above do the same thing. The first two are what you might do from within a Wire derived object or module. And the rest are what you might do from a template file or related (like init.php or ready.php). The last (shortest) example would require that the 'hello' API variable had been set before the file that it's in (like a template file) had started rendering. See the wire() method documentation for more.

@Joss Still seeing that error after yesterday's update/fix to 3.0.29? Just wondering if this is the same issue mentioned by fuzendesign above (which has been fixed) or if what you are seeing is still present. I'm guessing it's fixed since both refer to the same line number, but wanted to double check.

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.