Leaderboard

There are always discussions how PW handles heavy sites. I redesign our webpage www.kentvitrini.com (Turkish City Portal -> News, events, directy etc) This page has now 49.500 news entries. On the left you see a list of states. If you click on any state then you see list of cities on the left . The numbers are the news count under each state or city. State and City names are UrlSegments in the url. In real it is whole running on the Home page but gets filtered by UrlSegment1 = State and UrlSegment2 = City. The news are pulled from a turkish news agency's RSS every 30 minutes with Cronjob. So the news list increases 1000-2500 news every day. This is not the final design and functionality. I put the site online to get Google indexes the pages. I am still working on the site. There will be a Company Directory, Events system and a ads system etc. I wanted to only shere to show you the performance of a website with 50.000 pages running on PW . Please note that i get 94% PageSpeed Score on Gmetrix without Google ads. So theese ads are slowing down the website. With ads i get only around 70% Score. P.S: This is not a Showcase post yet. so did not post it to the Showcase section. When it is totaly ready then i will share it there again.

When I started working professionally on web projects... (don't you just love when folks start with that? "oh man, it's going to be another rant!") ... some of the first CMS' I had the pleasure to work with were kind of "static site generators": they generated static HTML files when you saved the content, and if your site had subdirectories, those were literal directories on the disk with more HTML files in them. I believe this was in part because server-side rendering back then was pretty darn slow and clunky, but also because it was easier to build a clean site structure with actual directories filled with static HTML files. "Dynamic" features, comment forms, polls, and whatnot were not quite as important back then, mind you. Now, I get that modern SSG's are a different beast in many ways, and I think they're actually pretty rad. What bugs me, though, is the amount of marketing bullsh... uhm, opinionated information floating around. Things like this gem from the staticgen.com website (emphasis added): I mean... how is this what a "typical CMS driven website" looks like? Any half-decent CMS has built-in caching support, at least to some extent, and caching plugins regularly pop up amongst those lists of most popular plugins for platform X. You don't need to be a rocket scientist to figure out that running a server-side rendered, CMS generated website with no caching whatsoever is a Very Bad Idea™. Comparisons like this may make the SSG approach sound good, but they've also got little to do with how things actually work. Without hopefully being too blunt, I don't think this is necessarily the best question to ask. If you define SSG as an application that reads markdown files from disk and generates a static site from those (that's one of the first definitions that comes up if you search for the term) then I don't see this as a solution most of us could push to our clients. At least not unless the site in question is a static one that doesn't need to update too often, and/or you can convince the client to pay you for each modification on a case-by-case basis. On the other hand if you think of an SSG as something that generates static site from dynamic content managed by some piece of software, well... that software you use to generate the content for the SSG? That's a CMS. It may be a headless CMS, but a CMS nevertheless ? I'm also going to agree with @MoritzLost on the point that ProcessWire + ProCache is indeed a kind of an SSG. Keeping a few potential pitfalls in mind one could definitely use this combination to build a setup that pre-renders the whole site and thus doesn't depend on request time server-side rendering. The web is full of interesting tech: headless CMS', static site generators, APIs, and whatnot. While the "best" choice depends on the use case — you would have to consider the pros vs. cons and figure out what's best for each particular project, client, and team — in my opinion it's also rarely all that important. Websites are created for end users and end users don't care what you're running the site on — as long as it works, serves their needs, is fast (enough), etc. ... and you can get that with any platform ? Sorry, that last part was a bit off-topic. Overall the SSG market is well worth keeping tabs on. Personally I tend to lean on the "dynamic CMS generated content rendered server-side with efficient caching policy" approach, but that's mostly because I feel it makes sense for the kind of projects and clients I tend to work with. Pros and cons ?‍♂️

11ty is great. It's super flexible and doesn't lock you into a certain way of using it or fixed templating. Static site generators make a lot of sense for anything in the realms of corporate or product marketing page. You can keep all the stuff, which rarely changes in plain html. Form submissions and such can just be sent to a different headless endpoint. There's also things like Netlify CMS or similar tools, which allow you to trigger rebuilds whenever something in the underlying data changes. This is nice if you don't want to involve a dev every time some copy changes. For more dynamic content like e.g. comments I'd still not use a static site generator. They make sense if the cost of rebuilding for each change is outweight by the simplicity of deployment / putting the site up somewhere, but not really if you're constantly rebuilding. I don't really subscribe to the idea of having highly dynamic content just rendered client side, but people do use ssg's as an alternative to the dreaded SPA. Dynamic content is still all loaded/rendered in js, but at least it's multi page with some static bits.

Static site generators will probably be 'the next big thing'. You get way better performance and security by default than you could have with any CMS by definition. Which doesn't mean that you can't have dynamic content like comments, e-commerce etc. But instead of bundling that functionality, you're using external services, APIs, serverless functions and build automation to persist data and trigger builds whenever something changes. I'd recommend reading the Jamstack book (created by the Netlify people), you can get the ebook for free and it explains all the concepts related to SSG. By the way, you don't need NodeJS / NPM to have a static site generator. Though many SSG are built with JavaScript, they use NodeJS only as a runtime for the build step, not as an actual server. But there are SSG written in all kinds of languages - check out this site if you want to find one you like. One could argue, by the way, that the ProCache module for ProcessWire is also kind of a SSG generator, even though it works a bit differently than most tools on that list. My current recommendation is eleventy, I'm currently rebuilding a couple of my own sites as well as a ProcessWire-related project that I might release soon with it ?

All has gone smoothly with the new master branch version of ProcessWire (3.0.164), officially released last week. Next week we’ll also be releasing 3.0.165 on the master branch, which will fix a couple minor issues that have surfaced. Though we are talking very minor, so there’s no reason to wait on upgrading. The dev branch commit log covers changes since 3.0.164. There will be more commits next week and then we’ll be on version 3.0.165 on both dev and master branches. This week, in addition to some minor core updates, I’ve been working on updates for both ProCache and FormBuilder. The ProCache updates primarily focus on providing better API functions for finding what’s cached, adding more hooks, and providing better control over when and how cached versions of pages originating from URL segments are cleared from the cache. On the FormBuilder side, I’ve been focused on improving our submitted form entry listing tools for the admin side. Prior to the version in progress, it hasn’t been possible to perform custom searches on submitted form entries, the way that you might do in Lister/ListerPro for pages. Nor has it been possible to sort by anything other than created or modified date. That all changes in this new FormBuilder version. Now you can search within and sort on any field in the entries listings. You can search and filter by any number of fields at once. You can select what fields/columns display, and in what order. You can export (CSV) rows that match your search criteria. It’s basically like a mini ListerPro, but for forms submitted on your site. So far I’m finding it extremely useful in testing here, and I'm excited to release it in the FormBuilder support board. Below is a screenshot. I should have this version released in the FormBuilder board in 1-2 weeks, along with some other updates to it. Thanks for reading this quick update and have a great weekend!

HI, I have done a few E-commerce projects in OpenCart, which really suitable for the mid-size E-commerce platform. I have tried Magento once but never get a knack on it. I tried to use ProcessWire for the E-Commerce but I realised I have to do a lot of custom coding which I am not that much expert. So I use different tools for different purposes, for any CMS related WEBSITE/WEBAPPS - ProcessWire is a rockstar for me. But for e-commerce I would go for OpenCart

Hi @ryan, I just noticed that part of the documentation for $user variable refer to Page objects instead of User object. Yes, technically, these are pages as well but I think it might confuse new ProcessWire users. In addition, the $user variable docs clear refer to users as 'users' and not 'pages'. Here's an example of what I mean. $users->delete() Here is the list of docs that need amending (that I could find): https://processwire.com/api/ref/users/add/ https://processwire.com/api/ref/users/added/ https://processwire.com/api/ref/users/delete-ready/ https://processwire.com/api/ref/users/deleted/ https://processwire.com/api/ref/users/find/ https://processwire.com/api/ref/users/save/ https://processwire.com/api/ref/users/save-ready/ (some bits are OK). https://processwire.com/api/ref/users/saved/ The get* methods and setCurrentUser() are all OK, referring to User object instead of Page object. The saveReady() refers to User object in some parts but Page object in others. For instance: But further down... Could you please consider amending these? Thanks.

Yes, I'm well aware that it is completely valid to have inputs and such outside of a form element and with email address EMO breaks the markup but I thought this was not the issue in your case since there was already previous post from creativejay about problems with FormBuilder and you also mentioned that EMO shoudn't touch values of form elements but you were literally talking about inputs and such, not the form element itself. Sorry about that. There are also another technically valid situations where EMO fails e.g. like having an email inside data attribute. Generally it is kind of compicated topic to automatically replace email address by new node in every possible case without breaking things. Anyway, current state where EMO skips whole content inside form element is not ideal since there are many cases where you can have email addresses inside form where they should get obfuscated but currenly are not. Like the one in my previous form example where email inside p element should be touched but it's not. That said maybe we should remove the form element completely from ignored elements and concentrate only at form elements (what you suggested actually) like input, option and textarea where most likely touching email addresses will give us headaches. I'll look into it.

Yep the problem is the one tpr describes. Beside that, you should consider the following: Don't build your urls manually, let ProcessWire do it for you: $action = $pages->get('/checkout/')->url; <form action="$action"> Sanitize input $id = (int) $input->urlSegment1; // Must be an integer Cache the page you're searching; I'm sure that ProcessWire also returns a cached page, but in theory, each $pages->get() call fires an SQL query: $myPage = $pages->get($id); // Assign the found page to variable $myPage if ($myPage->id) { // Make sure we found a page echo $myPage->title; } Escape output $title = $sanitizer->entities($myPage->title); echo "<input type='text' name='product' value='{$title}'>"; Edit: This is only needed if your title field does not have the "HTML Entitiy Decoder" textformatter applied. Cheers

When I need a calculated field that will be used for sorting, I like to add a hidden (or regular, doesn't matter) field to the template to store the calculated value. The value gets automatically calculated on page save. A hook like this in your /site/templates/admin.php can do the work for you: $pages->addHook('saveReady', function($event) { $pages = $event->object; $page = $event->arguments(0); if($page->template == 'rider') { $miles = 0; foreach($page->rides as $ride) { $miles += $ride->miles; } $page->miles_ridden = $miles; } }); Then when it comes to sorting, you just sort on your calculated field: miles_ridden. If you are adding this to an existing PW installation, then you'd need to establish the initial values for each rider's miles_ridden. This could be done with a quick bootstrapped script: /setup-riders.php <pre><?php include("./index.php"); foreach(wire("pages")->find("template=rider") as $rider) { $rider->save(); echo "$rider->name: $rider->miles_ridden miles ridden\n"; } Then you'd just load domain.com/setup-riders.php in your web browser, and then delete the file when done.