Leaderboard

Looks like someone (apparently a single user) has been going around forums and vulnerability databases posting about a ProcessWire "local file inclusion" vulnerability, claiming that in a specific old version of ProcessWire (2.4.0) simply passing "download" GET attribute to index.php is enough to download any local file on the system, including files that may be outside the ProcessWire installation path. This is not a real ProcessWire vulnerability — this kind of argument has never existed in any version of the system. Simply put the report is either fake, mistake, or there could be some custom-built vulnerable piece of code (or other vulnerable software) on the host resulting in this behaviour. We take such claims seriously, however unlikely they may seem, so just to make sure I've just checked parts of the codebase in both 2.4.0 (where this is supposedly occurring) as well as various later versions, and there's zero evidence to back this claim up. I've also manually tested this on various setups, including a brand new 2.4.0 installation, to no avail. (Note: I wouldn't post about this here unless the original claim was relatively widely spread. Just felt it made sense to clear things up.) --- That being said: as one builds sites using ProcessWire (just like with any other system) they need to be careful not to introduce vulnerabilities of their own. ProcessWire is armed with brilliant tools for preventing common vulnerabilities — the selector engine helps avoid various SQL issues, Sanitizer has many tools for cleaning up dirty data, SessionCSRF makes implementing proper CSRF protection downright trivial, etc. — but it can't protect you automatically from every mistake ? More security tips: https://processwire.com/docs/security/.

This week I’ve continued work on the new modules directory and today have launched an updated version of it on the site. This is just an initial version of it, as there’s still plenty to do. But the basics are up and running if you’d like to take a look at https://processwire.com/modules/ The new modules site is using ProcessWire’s multi-instance support to boot a copy of modules.processwire.com and to pull and manipulate data from it. In order to prevent content duplication, I’ve setup most of the pages at modules.processwire.com to redirect to their equivalent versions in processwire.com/modules/. There’s not much new here in terms of data that is being displayed, though it is also different in several ways. For starters, it finally has the look-and-feel of the main site. The modules homepage takes a different approach and lists 3 modules each in these different sections: Recently added modules Recent updated modules Popular modules Modules recently liked by users Modules in the “recently updated modules” section are those that have had recent commits at GitHub. The “popular modules” section randomly selects 3 modules that have a certain threshold of “likes” quantity and date of user activity, combined with being updated within the last 6 months. Or you can view them all (no random selection) at the dedicated popular modules page ... this section will grow as users interact with it. The “modules recently liked by users” section looks for modules that have had the “like” button clicked on recently, and puts them into this bucket. Like the “popular modules” section, this one will grow and increase in relevance once there is more user interaction with the new modules directory. There’s also a new feature on this modules site where you can maintain a “cart” (of sorts) that keeps track of which modules you have liked. In addition, the new modules site estimates how much usage each module has by analyzing request data from the ProcessWire modules web service. This is something the old modules site does not do. It uses this data solely for providing a unique sortable view of modules. Because this data hasn’t been tracked for long, it’ll increase in relevance over time. One area that I want to build out quite a bit more is the module “authors” section. Since the new modules site will be using authenticated login sessions with LoginRegisterPro, we’ll be able to maintain a lot more “profile” info for module authors (full name, bio, photo, website, anything else?) There are a few things still in development, so you won’t see them just yet: Edit module ability (it directs you to the old modules site for that) Add module ability (also directs you to the old modules site) Informational pages (how to install modules, etc.) More to come here, but that’s where it is now. Nothing all that exciting I know, but still an improvement hopefully. If you find anything that isn’t working, or have other feedback or suggestions, please let me know. Thanks for reading and have a great weekend!

Hello community! I want to share a new module I've been working on that I think could be a big boost for multi-language ProcessWire sites. Fluency is available in the ProcessWire Modules Directory, via Composer, and on Github Some background: I was looking for a way for our company website to be efficiently translated as working with human translators was pretty laborious and a lack of updating content created a divergence between languages. I, and several other devs here, have talked about translation integrations and the high quality services now available. Inspired by what is possible with ProcessWire, I built Fluency, a third-party translation service integration for ProcessWire. With Fluency you can: Translate any plain textarea or text input Translate any TinyMCE or CKEditor (inline, or regular) Translate page names/URLs Translate in-template translation function wrapped strings Translate modules, both core and add-ons Installation and usage is completely plug and play. Whether you're building a new multi-language site, need to update a site to multi-language, or simply want to stop manually translating a site and make any language a one-click deal, it could not be easier to do it. Fluency works by having you match the languages configured in ProcessWire to those offered by the third party translation service you choose. Currently Fluency works with DeepL and Google Cloud Translation. Module Features Translate any multilanguage field while editing any page. Translate fields in Repeater, Repeater Matrix, Table, Fieldset Page, Image descriptions, etc. Translate any file that added in the ProcessWire language pages. It's possible to translate the entire ProcessWire core in ~20 minutes Provide intuitive translation features that your clients and end-users can actually use. Fluency is designed for real-world use by individuals of all skill levels with little to no training. Its ease-of-use helps encourage users to adopt a multilanguage workflow. Start for free, use for free. Translation services supported by Fluency offer generous free tiers that can support regular usage levels. Fluency is, and will always be, free and open source. Use more than one Translation Engine. You may configure Fluency to use either DeepL, Google Cloud Translation, or both by switching between them as desired. AI powered translations that rival humans. DeepL provides the highest levels of accuracy in translation of any service available. Fluency has been used in many production sites around the world and in commercial applications where accuracy matters. Deliver impressive battle-tested translation features your clients can count on. Disable translation for individual fields. Disable translation for multilanguage fields where values aren't candidates for translation such as phone numbers or email addresses Configure translation caching. Caching can be enabled globally so that the same content translated more than once anywhere in ProcessWire doesn't count against your API usage and provides lightning fast responses. Set globally ignored words and text. Configure Fluency to add exclusionary indicators during translation so that specific words or phrases remain untranslated. This works either for specific strings alone, or present in other content while remaining grammatically correct in translation. Choose how translation is handled for fields. Configure Fluency to have buttons for either "Translate from {default language}" on each tab, or "Translate To All Languages" to populate every language for a field from any language to any language you have configured. No language limits. Configure as few or as many languages as you need. 2, 5, 10, 20 language website? Absolutely possible. If the translation service you choose offers a language, you can use it in ProcessWire. When new languages are introduced by third parties, they're ready to use in Fluency. Visually see what fields and language tabs have modified content. Fluency adds an visual indication to each field language tab to indicate which has different content than when opening the edit page. This helps ensure that content updated in one language should be updated in other languages to prevent content divergence between languages. Render language meta tags and ISO codes. Output alt language meta tags, add the current language's ISO code to your <html lang=""> attribute to your templates that are automatically generated from accurate data from the third party translation service. Build a standards-compliant multi-language SEO ready page in seconds with no additional configuration. Render language select elements. - Fluency can generate an unordered list of language links to switch between languages when viewing your pages. You can also embed a <select> element with JS baked in to switch between languages when viewing your pages. Render it without JS to use your own. Manage feature access for users. Fluency provides a permission that can be assigned to user roles for managing who can translate content. Track your translation account usage. View your current API usage, API account limit, and remaining allotment to keep an eye on and manage usage. (Currently only offered by DeepL) Use the global translation tool. Fluency provides translation on each field according to the languages you configure in ProcessWire. Use the global translation tool to translate any content to any language. Use Fluency from your templates and code. All translation features, usage statistics, cache control, and language data are accessible globally from the $fluency object. Perform any operation and get data for any language programmatically wherever you need it. Build custom AJAX powered admin translation features for yourself. Fluency provides a full RESTful API within the ProcessWire admin to allow developers to add new features for ProcessWire applications powered by the same API that Fluency uses. Robust plain-language documentation that helps you get up to speed fast. Fluency is extremely easy to use but also includes extensive documentation for all features both within the admin and for the Fluency programming API via the README.md document. The module code itself is also fully annotated for use with the ProDevTools API explorer. Is and will always be data safe. Adding, upgrading, or removing Fluency does not modify or remove your content. ProcessWire handles your data, Fluency sticks to translating. Full module localization. Translate Fluency itself to any language. All buttons, messages, and UI elements for Fluency will be presented in any language you choose for the ProcessWire admin. Built for expansion. Fluency provides translation services as modular "Translation Engines" with a full framework codebase to make adding new translation services easier and more reliable. Contributions for new translation services are welcome. Fluency is designed and built to provide everything you need to handle incredibly accurate translations and robust tools that make creating and managing multi-language sites a breeze. Built through research on translation plugins from around the web, it's the easiest and most friendly translation implementation for both end users and developers on any CMS/CMF anywhere. Fluency complements the built-in first class language features of ProcessWire. Fluency continues to be improved with great suggestions from the community and real-world use in production applications. Big thanks to everyone who has helped make Fluency better. Contributions, suggestions, and bug reports welcome! Please note that the browser plugin for Grammarly conflicts with Fluency (as it does with many web applications). To address this issue it is recommended that you disable Grammarly when using Fluency, or open the admin to edit pages in a private window where Grammarly may not be loaded. This is a long-standing issue in the larger web development community and creating a workaround may not be possible. If you have insight as to how this may be solved please visit the Github page and file a bugfix ticket. Enhancements Translate All Fields On A Page Compatibility with newest rewrite of module is in progress... An exciting companion module has been written by @robert which extends the functionality of Fluency to translate all fields on a page at once. The module has several useful features that can make Fluency even more useful and can come in handy for translating existing content more quickly. I recommend reading his comments for details on how it works and input on best practices later in this thread. Get the module at the Github repo: https://github.com/robertweiss/ProcessTranslatePage Requirements: ProcessWire 3.0+ UIKit Admin Theme That's Fluency in a nutshell. The Module Is Free This is my first real module and I want to give it back to the community as thanks. This is the best CMS I've worked with (thank you Ryan & contributors) and a great community (thank you dear reader). DeepL Developer Accounts In addition to paid Pro Developer accounts, DeepL now offers no-cost free accounts. All ProcessWire developers and users can use Fluency at no cost. Learn more about free and paid accounts by visiting the DeepL website. Sign up for a Developer account, get an API key, and start using Fluency. Download You can install Fluency by adding the module to your ProcessWire project using any of the following methods. Method 1: Within ProcessWire using 'Add Module From Directory' and the class name Fluency Method 2: Via Composer with composer require firewire/fluency Method 3: Download from the Github repository and unzip the contents into /site/modules/ Feedback File issues and feature requests here (your feedback and testing is greatly appreciated): https://github.com/SkyLundy/Fluency/issues Thank you! ¡Gracias! Ich danke Ihnen! Merci! Obrigado! Grazie! Dank u wel! Dziękuję! Спасибо! ありがとうございます！ 谢谢你

@ryan - I see that the PW Upgrades module is now seeing pro modules, which is awesome, but I wondering if you and @netcarver could work together so that his awesome ModuleReleaseNotes module can read the processwire.com git host so we don't get this error: Sorry, ModuleReleaseNotes doesn't know how to connect to the git hosting service at processwire.com. Also, PW Upgrades is reporting that FieldtypeTable has a new version: 1.0.0 but when I go to the downloads post for Profields, it still has 0.1.9 as the latest download. And, if I try to upgrade to 1.0.0, then I get this error: ProcessModuleInstall: Unable to open ZIP file, error code: 19

@picarica Could you please use a more civilized language in here? I'm no PW forum admin, but I'm pretty sure the F*** word is not welcome here. If you have a problem with that particular module, you should post your question in the respective support forum instead:

Hi friends, just 7 months ago, I was "just" a designer and a rather semi-developer, still struggling with WordPress sites and more often than not delegating that work to pros. ProcessWire really helped me realising that it's not that hard after all (well it's still hard but it's doable) and you learn a lot just by doing it which has to be true for all developers anyway. So I started coding myself, I might also have to thank the 2020 pandemic to help me focus a bit more than usual, I created a bunch of websites using PW already – one of which I can't wait to put on showcases but it's still not live yet. That is one big personal milestone for me. The next milestone would be to give something back, and so I'd like to take on contributing some code I wrote, namely a event calendar for anyone to use. It's my first attempt doing this so please don't eat me alive. It's not a PW module yet (that's the plan however) just a git but I'm positive it will be useful once it works – well it works but it still needs more work – because if I had found a module that came close I wouldn't have started coding it myself :D With that, I will appreciate all input, be it how to improve the .js (probably especially), or the templates, or guidance how to proceed turning this into a PW-module, and of course, in that last process, no pun intended, suggestions to make it more versatile for different needs. git: github.com/bbblgmsp/ProcessEventCalendar demo: http://foobar.roofaccess.org/events/ Thank you!

Hi all, After seing the website featured in the latest Processwire weekly (thank you @teppo !!), I thought it could be nice to post some details here. I have actually made a few websites using Processwire, but it's the first time I'm posting one in the showcase. Backstory I made a first version of this website in end-2017 when I was starting to use Processwire after a friend recommended it to me. I was in charge of the front/back-end, and helped a bit on the design. At the time there was a slideshow of featured projects as the homepage, the project page was the only template with content blocks, and the information pages (about / contact) were specific templates. About the content blocks, I didn't know about the Repeater Matrix module so I kinda implemented my own, having a simple Repeater with a Select Options field defining which fields to display. All in all the website was pretty nice when it came out and I learned a lot in the process, but this year the agency wanted an update to fit their new narrative, so it was a nice opportunity to make some due changes. Back-end Modules I used : Repeater Matrix ProCache Seo Maestro Email Obfuscation Inputfield Chosen Select Color Minimal Fieldset Page Field Edit Links Runtime Only Tracy Debugger (of course!) This new version is all about content flexibility. The information pages now all share the same template, allowing them to create as many as they want. Each visible templates ("home" / "page" / "project") contains a Repeater Matrix field for content blocks, with 15 different types to choose from and options to add variations in the layout. Front-end To answer to the PW Weekly : it is indeed all custom-made except for three external libraries : plyrjs, flickity and lottiejs. I really like sveltejs but I still have to figure out how I could mix it with PW in my process. The animation in the introduction is described by a .json file and displayed as a SVG using Lottie. The transition colors can be changed. The menu order is defined by the manual sorting in the admin... I don't really know what to say here since it's all hand-made, let me know if you have any question! Screenshots Thanks !

The module uses an object "PageFieldValue" which holds the hydrated data from the database and gets initialized by the fieldtype: https://github.com/wanze/SeoMaestro/blob/master/src/PageFieldValue.php Each meta data group has its own class to render specific data, e.g. this one for the "meta" group: https://github.com/wanze/SeoMaestro/blob/master/src/MetaSeoData.php Hope that helps a bit ?

This is intentional; specific system pages are by default only displayed to the superuser role. Trash is a special case that may be displayed to non-superusers as well. Whether this decision makes sense is, of course, another question. In my experience it has been a good thing, and I've never personally come across a reason to display the Admin area to non-superusers that wouldn't be better solved in some other way ?

Hello Ryan, thanks for the update and yes the new page is more the look-and-feel of the main page. I'd like to give you a short feedback on two points I noticed during the first view/trial. 1. I have to admit that I personally am a person who likes to visually perceive larger lists. That is to say, I appreciated the fact that in the old page a small picture of the author was displayed with each module entry. I have to admit, if I have a list of 25, 40 or 50 modules in front of me and all entries look "the same" I knew in the past, I'm now looking for a module of author x, who has his picture looking like this... and then I "scrolled" over the search result quite fast. Would it be possible to include this module Autor Avatar in the new directory? 2. The second point concerns the search function in the module directory. Currently it seems to me as it looks like it probably does not search in the "body" area. Would this be possible? Explanation: The following problem occurred during my first test, the first module which I always install with every new PW installation is the "ProcessWireUpgrade" module. So my difficulty was, I can't remember the exact name ... don't ask why, I already tried it with postits etc. etc. ... nothing helps. ? So I entered "Update" in the search field (I know update and upgrade is not the same thing) and it gives me only one entry here: "MarkupBrowserUpdate" ? but that's not what I was looking for. I knew that the module is from you, so I clicked on your name in the author's section and went through all your modules and see, it's not update but upgrade. OK the search can't find anything, but the word "update" does appear in the body text, so why doesn't it show me this? Long speech, short sense... wouldn't it be helpful if the search function would also search the body area? Or a completely different idea (I'm working a lot with the blog system right now) how about a hashtag function for the modules? The module author can then enter 1, 5, 10, ... Keywords to be included. Or would even both be helpful? Only my two cents, thanks for reading and a nice weekend

@adrian Thanks, pagination fixed. I meant to mention about non PW3 modules above, that I'm going to be removing them from the directory, or at least from the generated lists that it outputs. I don't think there's any need for the directory to maintain PW2 modules anymore, but I wanted to go through them one-by-one just in case there are any that are mislabeled as PW2, or maybe some are still actively developed and work with PW3. But the reason the new modules directory doesn't say anything about PW version is because it was going to be exclusive to PW3 compatible modules going forward.

Oh awesome - thanks for pointing that out. I have updated the module to use this and it seems to be working fine.

No need to change the module with the Google API keys. You can retrieve the title with oEmbed by using a url like this: http://www.youtube.com/oembed?url=http%3A//youtube.com/watch%3Fv%3DM3r2XDceM6A&format=json For more info check here.

FieldtypeGridSpace A grid selector for space design An input field for placing DOM elements in horizontal grids based on Bootstrap grid system. Module URL: https://processwire.com/modules/fieldtype-grid-space/ Here is the github https://github.com/carlitoselmago/FieldtypeGridSpace With updated images of backend and frontend example

Hello, I'm very new to ProcessWire but already fell in love with this CMS/CMF! I just finished my first small project and as I saw a lot of questions and different answers in this forum on how to set up a nice language switcher for your website, I decided to write my first tutorial. ---------- Please note: I rewrote this tutorial since I was made aware and learned that flags should not be used for language selectors! There are some threads here in the forum (and from external sources) where this question is discussed: https://processwire.com/talk/topic/13196-adding-image-field-to-language/ http://daily.unitedlanguagegroup.com/stories/editorials/inside-design-language-selector-no-flags https://processwire.com/talk/topic/16524-extending-languages-template/ http://www.flagsarenotlanguages.com/blog/why-flags-do-not-represent-language/ https://processwire.com/talk/topic/14241-language-names-and-utf8-page-names/ Thanks, @ottogal @bernhard @jmartsch @kongondo an all others for your hints! ---------- TUTORIAL - Set up a nice language switcher for your website - here we go: This will be the desired result! Step 1) Setup at least 2 languages in your PW install. In my case it's German (default language) + English: Step 2) Add a custom field Type = Text Name = languagecode This will hold the ISO 639-1 two-letter language code for the respective language. The field is needed to provide a simple method for outputting the language code in your templates. Without this field, you will need to programmatically construct your two-letter language code output via PHP (at least for the default language, as ProcessWire doesn't allow to rename the default language and it will always be called default). Here is an overview for ISO 639-1 two-letter language codes: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes Step 3) Add this field to the system template: language. To achieve this, go to Setup / Templates and activate the filter Show system templates: Now you can add the previously created field languagecode to the language template. Step 4) Edit your languages and fill in the appropriate values. a) default (German) Name = default (this can't be changed and is read only) Title = Deutsch (in both language tabs! - this is important as your visitor should always see his language item ... in his language) languagecode = de b) english (English) Name = english Title = English (in both language tabs! - this is important as your visitor should always see his language item ... in his language) languagecode = en Step 5) Now we are ready to write our template output! As we already have the appropriate two-letter ISO language code (languagecode field), we can use this in our html lang property: <html lang="<?php echo $user->language->languagecode; ?>"> Also the rel alternate output in the html head is simple. Put the following code within your <head></head> area: <?php // Handle output of 'hreflang' link tags for multi-language (SEO!) foreach ($languages as $language) { if (!$page->viewable($language)) { continue; } // Get the http URL for this page in the given language $url = $page->localHttpUrl($language); // Get the language code using custom languagecode field $languagecode = $language->languagecode; echo PHP_EOL.'<link rel="alternate" hreflang="'.$languagecode.'" href="'.$url.'">'; } ?> In my sample I've used Boostrap 4 and the code below shows a complete navbar with our language switcher (BTW the language switcher will always be visible, even when the bootstrap navbar is collapsed): <nav id="mainnav" class="navbar navbar-expand-lg navbar-light px-4 px-md-5 sticky-top"> <a class="navbar-brand" href="<?php echo $config->urls->root; ?>"> <img src="<?php echo $config->urls->templates; ?>images/logo-rund-80x80.png" alt=""> Your Site Title </a> <ul class="navbar-nav ml-auto mr-3 mr-lg-0 order-lg-last d-none d-xs-custom-flex language-switcher" aria-label="<?php echo __('Sprache wechseln') ?>"> <?php echo '<li class="nav-item dropdown">'; // Construct the language prompt in the current user language $prompt = $user->language->title.' ('.strtoupper($user->language->languagecode).')'; // Current language = dropdown-toggle echo '<a class="nav-link dropdown-toggle" href="#languages" id="language-select" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">'; echo '<span class="world-icon"></span><span class="sr-only">'._x('(aktuelle Sprache)', 'navigation').': </span> '.$prompt; echo '</a>'; echo '<div id="languages" class="dropdown-menu dropdown-menu-right" aria-labelledby="language-select">'; foreach ($languages as $language) { // Get the http URL for current page in the given language $url = $page->localHttpUrl($language); // Construct the language prompt in the given language $prompt = $language->title.' ('.strtoupper($language->languagecode).')'; // Next language item (except current language) if ($user->language->id != $language->id) { if (!$page->viewable($language)) { echo '<span class="dropdown-item disabled">'.$prompt.'</span>'; } else { echo '<a class="dropdown-item" href="'.$url.'">'.$prompt.'</a>'; } } } echo '</div>'; echo '</li>'; ?> </ul> <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarMainMenu" aria-controls="navbarMainMenu" aria-expanded="false" aria-label="<?php echo __('Menü einblenden / ausblenden') ?>"> <span class="navbar-toggler-icon"></span> </button> <div class="collapse navbar-collapse my-3 my-lg-0" id="navbarMainMenu"> <ul class="navbar-nav mr-auto"> <?php // Top navigation consists of homepage and its visible children foreach ($homepage->and($homepage->children("template=main-page|news|contact-points")) as $item) { if ($item->id == $page->rootParent->id) { echo '<li class="nav-item active">'; echo '<a class="nav-link" href="'.$item->url.'">'.$item->title.'<span class="sr-only"> '._x('(aktuelle Seite)', 'navigation').'</span></a>'; echo '</li>'; } else { echo '<li class="nav-item">'; echo '<a class="nav-link" href="'.$item->url.'">'.$item->title.'</a>'; echo '</li>'; } } ?> </ul> </div> </nav> That's it! I hope you will like my tutorial and if there are any questions, critics or improvements please let me know! Thanks, Martin

I've had similar experiences on a project of mine, which was quite a bit smaller, but also quite a bit less spec'ed in terms of server resources. What I noticed was the big hit of loading all the templates/fields upfront for each request, which added quite a hefty ms count to requests for somethings that hardly ever changed and it needs to be done before any actual work related to the request can be started. About a year ago we decided to go for a rewrite though, but that might be a place to look into for optimization. Also as with any other project using sql you want to look out for n+1 queries, which are actually quite easy to create with processwire as fields are loaded magically on demand. You can use autojoin manually as option for $pages->find() if needed to mitigate those. I'd also care more about the number of sql requests and less about how many joins they use. Joins can be a performance hit and sometimes 2 queries might be quicker than one with a join, but 1000 queries for a single page request sound unnecessarily many.

A stock PW3 installation should actually be faster than PW2 – it certainly is on all of my installations. There's a lot more optimization in PW3 than in PW2. If that's not what you are seeing, then it's time to start looking for where the bottleneck is. PW3 does not have more significant overhead than PW2 except when it is compiling a file for the first time. The 30% increase numbers mentioned above sound to me like that is a request where PW is compiling a file. You can expect a request where it has to re-compile a file to take longer. But it only has to do that once, when a file changes and needs to be re-compiled. Maybe that's a common occurrence on a dev site, but should be a rare one on a production site. I'm measuring here with Chrome dev tools, ProfilerPro and my own timers using the Debug class. What tool are you guys using to measure times, and in what quantity? Before deciding something is PW3 related, I really suggest testing with a basic/blank profile without other modules installed. If you are consistently seeing any kind of increase in render times under PW3, my guess would be that something is getting recompiled on every request for some reason or another, or that there is another module involved that runs slower under PW3 for some reason. Edit--A few things to add: Debug mode is going to be slower in PW3 than in PW2, simply because PW3 is tracking a lot more stuff than PW2 did. With debug mode off there should be no difference though. Keep in mind debug mode is for development, and not something you should ever leave enabled on a production site. PW3 is more efficient with resources than PW2. PW3's boot time (stuff it does before executing your template file) is 20% to 45% faster in my testing. PW3 executes 20% to 25% fewer queries as part of the boot, and loads up to 50% fewer pages. Autoload modules become part of the boot process, so I test with no 3rd party modules installed. The file compiler can potentially add a little bit of overhead even when it doesn't need to compile, because it has to determine whether something needs compilation. But on a default site profile we're talking about maybe 10ms at the most here. If you turn off the template compiler, then that overhead is gone. While PW3 uses fewer resources on the database side, but sometimes more resources on the file system side. If you've got a slow file system, you might notice it more in PW3 than in PW2. For those of you seeing PW3 to be slower than PW2, if it's determined that 3rd party modules are not a factor, I would be curious what's happening in the template files. Perhaps there is a bottleneck in a certain API call or something that we're not aware of yet. It would be interesting to see the results of profiling the API calls in your template files using ProfilerPro or Debug::timer() calls. Mostly specific to Soma: PW2 and PW3 are identical in terms of how they use joins and indexes. Regardless of version, PW will use as many joins as it takes to execute the selector you give it. Just like you can create complex or inefficient SQL queries you can also create equally inefficient $pages->find() calls if you aren't being careful. Using PW's API doesn't mean you are somehow bypassing the database. Your find() queries still become SQL queries. So if you are working on big and complex projects, then you need to watch and profile your work. When you a come across a complex find() operation that is expensive, refactor it to be simpler or break it down into smaller parts. Pay attention to how many pages you load in memory at once. Don't use find() and children() calls without "limit" selectors when dealing with potentially large sets. With regard to indexing, PW logically indexes all the columns that are likely to be used in find() operations, but if you are querying columns in a table have no index for whatever reason (3rd party module that forgot an index, or column not commonly used for queries), you may need to add one. Most of us never need to do this, but since you mentioned "big and complex" you may be in the territory where you have to apply more consideration to these things.