PrevRebuilding the ProcessWire.com website (part 5)
Happy New Year! This week we’ll take a quick look at last week’s new master version launch and then discuss the status of the new ProcesssWire.com website currently in development. More
In this week’s post, we’ll take a look a look at the new website and focus on some parts of it and how they were built. Then we’ll dive into the latest version of ProcessWire on the dev branch, version 3.0.124.
This week I’m happy to say we’ve got a new website online! Though if you are reading this, then you already know that. It is the best I could do with the time I had, and of course it’s not anywhere near perfect, and perhaps there’s still plenty of work to do in some spots. But hopefully we’re now in a much better spot for attracting new users than we were before, as things are now more up-to-date. Like the ProcessWire core, it’ll be an ongoing project where we’ll be constantly improving it. Thanks to everyone that’s been testing and contributing ideas and feedback.
The site is using these non-core modules (in A-Z order):
The Uikit 3 framework was used on the front-end, which of course we’re also using on the back-end in AdminThemeUikit. PhpStorm was used as the editor to develop all the PHP, JS and SCSS files in /site/templates/. The SCSS files are compiled, merged and minified by ProCache (which uses scssphp behind the scenes). The JS files are also merged and minified by ProCache. Tracy Debugger was used during most of the development to save time in tracking down code issues.
The ProcessWire templates use Markup Regions and the Functions API exclusively, two relatively recent additions to the core that I really like to use and recommend.
About the Functions API
Some of you expressed confusion about the functions API examples, and I’ve found there really hasn’t been much written about it, and there needs to be. So I’m going to give that some attention next week. When it comes to your front-end template files, the functions API really has some major advantages over API variables, which is why I use them almost exclusively now. I’ll outline why you might like using the functions API in your template files too. Whereas, when it comes to development of modules (or the core), that’s where API variables have the advantage. Of course, these functions and API variables are one and the same thing, just that one begins with a $ and the other ends with (). But those little details mean big things when it comes to potential benefits of one over the other. Stay tuned for the details on this next week.
One of the most fun parts to build was the Showcase section, which showcases sites running ProcessWire. Beyond just the look and feel, there are a lot of improvements relative to the same section on the old site.
URL verification
All the sites are re-verified every few months (using the Verified URL Fieldtype available in ProFields). Not only does it verify that each site’s URL isn’t returning HTTP error codes, but it also verifies that that the site appears to be running ProcessWire. Sites that don’t have the expected indicators of running PW go into a manual review queue. Using this process, we can more quickly identify and remove sites from the directory that don’t appear to be applicable to ProcessWire.
Lazy loading
One useful aspect of the Showcase section is that the images for sites are lazy-loaded. So while it may present a lot of sites to look at, the images don’t load until they are close to your viewport as it relates to scrolling or your position in a slider.
Likes and direct site links
A couple of other useful things to point out… You can “like” any site in the directory, anywhere that it appears (even the homepage) by clicking the heart icon that shows in the top right corner when you hover over any site in the directory. In addition, while we maintain a details page for every site in the directory, you can go directly to any site by clicking its URL that appears on the hover box. Click anywhere else in the hover box and it’ll go to the details page hosted here.
Randomization and equal time
Lastly, the Showcase main page gets randomized once daily so that it’s showing you sites from different categories every day. Though the latest additions are always shown near the top (though never first at the top), since it is likely to be one of greater interest. The reason we don’t show it first at the top is that, while we get some amazing and beautiful sites submitted, we also occasionally get sites that might be political, religious or otherwise controversial in nature, or maybe just a little hairy looking, and we don’t want that to be the first thing that someone sees on the Showcase page.
Another part of the site that if significantly improved relative to the old site is the search engine. The search independently searches the ProcessWire API, 3rd party ProcessWire modules, Blog, Showcase and the rest of the site. It also provides a shortcut for searching the forums. It bundles all of this into a live search with results that appear as you type. You can also view all results on the dedicated filterable search landing page. It’s a whole lot of power for a site search, and whatever you might be looking for, this helps you find it a lot quicker than was possible on the old site.
The search engine is powered by a module I’m developing to add to the ProDevTools set of modules. Though so far it is a PHP class rather than a module. I’m working to turn it into a more general purpose tool for use outside the PW website and it will be converted to a module.
Most of the pages in the site are cached by ProCache, and they are re-rendered once daily. But every page in the site has that footer at the bottom that is showing you the latest forum posts, Tweets, and PW Weekly edition. The latest forum posts are particularly dynamic, sometimes changing by the minute. So how does it keep this up-to-date? Well, actually it doesn’t, unless and until you scroll to it.
When you are getting close to having the footer be visible, it sends off an Ajax request to another page that renders nothing but the footer, but on a significantly shorter cache time (1-2 minutes). This enables us to have fully cached page delivery throughout the site, while showing you information in the footer that is always up-to-date when/if you happen to scroll to it. On the old site, the information that you saw in the footer always followed the cache time of the rest of the page, making it typically out of date. So this is yet another nice improvement on the new site.
The ProMailer module handles the management of newsletter subscriber and distribution of the weekly newsletter. It actually just finished sending its first distribution, and all seems to have gone well. It’s much more full featured than on the old site, in that I didn’t have a dedicated tool, so I manually managed subscriptions and un-subscriptions. Now the new ProMailer module takes care of it all, and even manages the double-opt-in confirmation process by email, as well as automatic expiration of subscribers that fail to complete the double opt-in. There’s no longer any manual labor involved in managing the subscribers. We’ve got the ProMailer module connected to our Mailgun account using the WireMailMailgun module.
Here's a list of performance-focused strategies we're using on the site:
In testing with Webpagetest.org we scored straight A’s and with Google Pagespeed Insights we received a score of 100 for desktop and 92 for mobile:
This is just phase 1 of the site, and there’s plenty left to do. There’s more documentation to write, more marketing copy to write, more screenshots to populate on various pages, and more features to add. The design is likely to evolve as well. On the homepage the goal is to replace the computer and rotating screenshots with an actual video, as soon as there is one we can use. There’s also the other sites like the Modules directory, the forums, the developer directory, and the cheatsheet, all of which need to be updated consistent with the new site as resources are available. Then there’s the multi-language side of the main site, which we’d like to enable and translate in the near future, but not until we’re pretty sure all the copy/text is relatively final.
Thanks again to everyone that’s helped out with the new site and we hope that you find it to be a nice improvement over the old site, which also served us very well for a long time. If you come across any other issues with the new site, please let us know in the forum.
This week we’ve also got a new core version. Here’s a quick summary of what you’ll find:
This new trim()
method added to the Sanitizer API variable is a much more powerful version of the trim() function that you might be familiar with from PHP. Both the Sanitizer version and the PHP version trim whitespace from the beginning and ending of a string. But to my surprise, the PHP version is pretty limited in terms of what it recognizes as whitespace. It knows nothing about the 30+ different kinds of whitespace available in UTF-8, and thus doesn’t trim them. Whereas our new Sanitizer version does. In addition to that, our Sanitizer version also trims out whitespace represented as HTML entities, things like
$emsp;
and several other named entities, as well as the 30+ different kinds of UTF-8 whitespace types when represented as hex encoded entities.
Our WireHttp client is used in ProcessWire to handle external HTTP connections, and is also available as handy tool for any of your own HTTP connection needs. But it relies upon PHP’s fopen()
being available for outbound http connections (which it often isn’t), and falls back to using sockets when fopen() doesn’t work. I’ve found that sometimes neither of those are available, so now WireHttp can also use CURL to handle the HTTP connection, and all the details are abstracted behind the class. What this means is that you are much less likely to ever run into a situation where you can’t use HTTP. You don’t need to know anything about what method WireHttp uses to manage your connection as it figures out what to use internally, and automatically falls back to other methods when one doesn’t work.
When a fatal error occurs, ProcessWire shows you a red error message, which is basically the contents of the original PHP fatal error message, combined with a debug backtrace. Now, the error handler can detect when you’ve attempted to use a functions available from the Functions API, but you don’t have it enabled in your $config. When this occurs, it’ll give you instructions for how to enable the Functions API, rather than showing you the “undefined function” PHP error message.
The MarkupQA class is what handles quality assurance of markup in Textarea fields, like CKEditor fields. It abstracts links to page IDs and thus automatically updates links to pages at runtime when something has been removed or renamed. Basically, it ensures that no matter where you move things around, or no matter how much you rename them, the links will always be up-to-date and without the need for redirects. We’ve given this quite a workout on the new PW site, as a lot moved!
The trouble is, it can be problematic when you’ve got lots of links that are to things on the same hostname that aren’t represented by ProcessWire pages. For instance, all the links within our API reference actually are generated dynamically and don’t exist as pages. Plus, all the links to threads in the forum are of course not ProcessWire pages. So whenever we save a page with those links on it, we get warnings about unresolved links. While not a huge problem, it is a bit of an annoyance. Now you can use a $config setting to tell MarkupQA to ignore some paths and not make any attempts to abstract them:
$config->markupQA = [
'ignorePaths' => [ '/api/ref/', '/talk/' ]
];
This goes in our /site/config.php file. In the above example, we are telling it to ignore paths that begin with /api/ref/ or /talk/. Now when we save pages containing links within our dynamically generated API reference, or somewhere in the forum, it will silently skip over them rather than telling us that it can’t resolve those links.
Thanks for reading and hope that you have a great weekend and week ahead. Enjoy reading the ProcessWire Weekly this weekend and stay tuned for more updates here next week!
28 December 2018
Happy New Year! This week we’ll take a quick look at last week’s new master version launch and then discuss the status of the new ProcesssWire.com website currently in development. More
25 January 2019 2
ProcessWire 3.0.125 has several useful new $sanitizer methods and options, as well as new ways to access them directly from the $input API variable. This makes dealing with user input even easier than it was before. This version also brings updates to our translation functions and improvements to… More
“…building with ProcessWire was a breeze, I really love all the flexibility the system provides. I can’t imagine using any other CMS in the future.” —Thomas Aull
Renobird
Ryan, the new site is killer! It looks great, and loads so figgin' fast it's crazy.
Reply
Mats
Amazing work as always, both with the new site and the PW updates!
Reply
Alexey
- 6 years ago
- 50
★★★★★Great work, I like the new site!
Reply
Matt
Great great work on the website Ryan & to everyone involved. Fantastic job.
Reply
Brendon Kozlowski
Ryan, with regard to the possible future ProDevTools Search module -- you didn't mention customizable "weighted" results; I'm wondering if that's something on the roadmap?
Ex: BLOG POST search results:
blog.title weight: 3
blog.body weight: 1
I'm GUESSING the search doesn't detect number of results within a field, simply whether it has a match or not; I'm also guessing it's not creating a tokenized word index for search results. So if only a blog title is matched it's +3 points. If only a body is matched it's +1 point; if both are matched it's +4 points. (I use +3, +1, +4 as there might be additional field weights applied.) Results are first sorted by weight, then by whatever other condition (created, published, etc.).
Just wondering. :) Thanks, as always, for all of the future thinking you're doing. I have a hard time keeping up, it's amazing.
Reply