Leaderboard

This module allows you and your site editors to protect a page (and optionally its children, grandchildren etc) from guest access directly from the page's Settings tab. You can also limit access to certain roles. http://modules.processwire.com/modules/page-protector/ https://github.com/adrianbj/PageProtector It makes it very easy for editors to set up various password protected areas on their site, or to simply protect a new page or section while they are still working on it. Ability for your site editors to control the user access to pages directly from Settings tab of each page Include whether to protect all children of this page or not Optionally allow access to only specified roles Option to protect all hidden pages (and optionally their children) Ability to change the message on the login page to make it specific to this page Option to have login form and prohibited message injected into a custom template Access to the "Protect this Page" settings panel is controlled by the "page-edit-protected" permission Table in the module config settings that lists the details all of the protected pages Shortcut to protect entire site with one click In addition to the admin interface, you can also set protection settings via the API: // all optional, except "page_protected", which must be set to true/false // if setting it to false, the other options are not relevant $options = array( "page_protected" => true, "children_protected" => true, "allowed_roles" => array("role1", "role2"), "message_override" => "My custom login message", "prohibited_message" => "My custom prohibited access message" ); $page->protect($options); As alway, I would love any feedback / suggestions for improvements. Hope you find it useful! Page Protection Settings (settings tab for each page) Module Config Settings

This is a very simple way to display some instructions to the admin users. Before starting, you need to write some docs; they can be a hidden branch of your page tree, using basic-page, or a different template of your choosing. You should make each subject it's own page under the docs so you can output each one under an accordion trigger. Required Module: Admin Custom Pages 1.) Follow all instructions to install the module; Also add the ACP_scripts_and_styles field to the admin template. 2.) Make a new page under admin, called Docs or whatever; assign the process as described in the module instructions. 3.) Make a template in your themes directory to generate the output of the docs page. 4.) Select that template from the page select in the admin custom page you created. 5.) also make a folder to keep your admin custom pages scripts and styles; 6.) create a css file to use for the display output and some basic styles (like ol, ul li etc..) 7.) Add the custom css file to your ACP_scripts_and_styles field. You can use any output you want, but i'm using a nested accordion, which is provided here: http://tympanus.net/codrops/2013/03/29/nested-accordion/ this is the content of the admin custom page: <?php $docs = $pages->get(4259); ?> <div id="docs"> <ul id="cbp-ntaccordion" class="cbp-ntaccordion"> <?php foreach($docs->children as $doc) { ?> <li> <h3 class="cbp-nttrigger"><?php echo $doc->title ?></h3> <div class="cbp-ntcontent"> <?php echo $doc->body;?> </div> </li> <?php } ?> </ul> </div> <script src="<?php echo $config->urls->templates ?>_admin_custom/js/jquery.cbpNTAccordion.min.js"></script> <script> $( function() { $( '#cbp-ntaccordion' ).cbpNTAccordion(); } ); </script> you'll also want to add the provided css, js and fonts that come with the Nested Accordion; in the css file you'll need to point the fonts to the actual font directory, for example: /site/templates/_admin_custom/fonts/icomoon_arrows/icomoon.eot it should come out looking something like this: *if you are using Reno theme, you can customize the icon, like for example fa-book, which is used in this example: -- Thanks & Credits to Diogo for originally creating the ACP module, and for Nico for getting it to work with the new admin theme system...

Pia - Pageimage Assistant Hello, today I can tell you that Pia Ballerina want to assist you with Pageimages and that can become really helpful! . . . Pia, in its current state, version 1.0.0, provides: a GUI (the module config screen) for quick and easy changes to the sitewide Pageimage default options an alternative way for calling the Pageimage resizing methods with PW selector strings three new methods as shortcuts to the resizing functions a new method called retinafy and its alias hiDPI, (introduced in version 0.2.0) . . . 2) Instead of ->width(), ->height(), ->size() you can call ->pia() now. With a PW selector string you tell Pia what image variation you want to have : . $image->pia("width=100, quality=80, sharpening=medium")->url; . If you want process ->width() just define width. If you want process ->height() only define height. If you want process ->size() just define width and height. If you want process ->size() with equal values for width and height, just define only size, or use the alias square: . $image->pia("width=480")->url; $image->pia("height=320")->url; $image->pia("width=400, height=300")->url; $image->pia("size=350")->url; $image->pia("square=350")->url; . So, yes, - I see. Now you may think: "Ok, nice looking girl, - and she can dance very well, - but for what should it be good that she is involved here? My very old buddies width, height and size - and me, - we don't need any Ballerinas between us!" . Yeah, I see what you mean. But this above is not what Pia is good for, this is just a little warming up for you. . In some cases one need to specify more than just width and / or height. If it comes to that you need explicitly populated options with the individual pageimages, Pia will become faster and more comfortable at some point. Also the code is looking more readable with Pia, at least to me: . // regular style #1: $image->width(800, array("upscaling" => false, "cropping" => true, "quality" => 80, "sharpening" => "strong")); // or regular style #2: $options = array("upscaling" => false, "cropping" => true, "quality" => 80, "sharpening" => "strong"); $image->width(800, $options); // now lets Pia dance: $image->pia('width=800, upscaling=0, cropping=1, quality=80, sharpening=strong'); $image->pia('width=800, upscaling=off, cropping=on, quality=80, sharpening=strong'); . For me it is that not only Pia begin to dance, my fingers do so too when writing selector strings instead of the regular array code. . Ok, last thing before we can go to stage: "You already may have noticed that Pia accepts few different values for boolean expression, yes?" for TRUE you can write these strings: "1, on, ON, true, TRUE, -1" for FALSE you may use one out of "0, off, OFF, false, FALSE" Ready? Ok, lets go to stage. . . . 3) Pia provide three new methods as shortcuts. This means that when using one of the shortcuts you have pre-populated options, regardless of the sitewide default settings: crop :: does what the name says contain :: is equal to the regular method: ->size($width, $height, array("cropping" => false)) cover :: this, Pias third child, is a new kid on the block . Let's have a closer look and compare it. We use Pias image from above as source for this example. (It's dimensions are 289 x 400 px) . . * crop $image->crop('square=100'); . it is 100 x 100 px and the name is: pia-ballerina_titel.100x100-piacrop.jpg . . . * contain $image->contain('square=100'); . it is 73 x 100 px and the name is: pia-ballerina_titel.100x100-piacontain.jpg . . . * cover $image->cover('square=100'); . it is 100 x 139 px and the name is: pia-ballerina_titel.100x139-piacover.jpg . . . Ok, you got it? . "Crop" crop out the area, "Contain" fits the image into the area, and "Cover" calculates the needed dimensions for the image so that the area is completly covered by it. . Following is a link with lots of those crop-, contain-, cover- variations. I have stress-tested it a bit: much variations . ---------- . . Later Additions: . * contain with option weighten Since version 0.0.6 contain can take an additional param called "weighten". (read more here) . . . * retinafy Since version 0.2.0 retinafy is added. It returns a markup string, e.g. a HTML img tag, where placeholders are populated with property values from the pageimage. Default properties are: URL, WIDTH, HEIGHT, DESCRIPTION. The method also can take an optional array with CustomPropertyNames. You also can use the alias HiDPI if you like. (read more here) . . ---------- . . You can get the module from the modules directory or from the repo on Github: . git clone https://github.com/horst-n/PageimageAssistant.git your/path/site/modules/PageimageAssistant . . Bye! . Classical ballet performance at the Aalto Theatre in Essen, in the context of the Red Dot Award ceremony 26 June 2007, Act III, Sleeping Beauty, the wedding reception Photos: Horst Nogajski - www.nogajski.de

Validation Module for ProcessWire, Validation module using GUMP standalone PHP data validation and filtering class. That makes validating any data easy and painless without the reliance on a framework. Usage almost same with original GUMP validation class. Extended original validation class for make it multi-language and added 2 new function 1 for field labels, 1 for set and get fields. Module Link

@nico and mademyday (just in case you don't know already) you can delete pages by clicking on "move" and then on the right "trash" since 2.5 https://processwire.com/blog/posts/processwire-2.5-changelog/#admin-theme-and-ui

I've gotten a little obsessed with the page loading time on my latest website. Many of you use AIOM for asset preprocessing, but I decided to use Grunt and htaccess for more control and a lighter server burden. Here are the techniques I used in a random order: For file versioning, I supply distant expiration dates and use this line in my htaccess: RewriteRule ^([^.]+)\.[0-9]+\.([^.]+)$ $1.$2 The file is referenced as "myfile.<?php echo filemtime("myfile.js"); ?>.js", though I do this in a function for additional path translation. MD5 would be another option, but it would take longer. For both Javascript & CSS (first converted from LESS), I first combine the multiple support libraries into one file. I include these files on the server as *.src.*; the templates includes the *.src.* files when the viewer is superuser. I then minify them and include them as *.min.*. I use Grunt to compress them all as *.*.gz and serve them as needed: <IfModule mod_headers.c> # Serve gzip compressed CSS files if they exist and the client accepts gzip. RewriteCond %{HTTP:Accept-encoding} gzip RewriteCond %{REQUEST_FILENAME}\.gz -s RewriteRule ^(.*)\.css $1\.css\.gz [QSA] # Serve gzip compressed JS files if they exist and the client accepts gzip. RewriteCond %{HTTP:Accept-encoding} gzip RewriteCond %{REQUEST_FILENAME}\.gz -s RewriteRule ^(.*)\.js $1\.js\.gz [QSA] # Serve correct content types, and prevent mod_deflate double gzip. RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1] RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1] <FilesMatch "(\.js\.gz|\.css\.gz|\.svgz)$"> # Serve correct encoding type. Header set Content-Encoding gzip Header set Precompressed true #for debugging # Force proxies to cache gzipped & non-gzipped css/js files separately. Header append Vary Accept-Encoding </FilesMatch> </IfModule> I needed to provide the main script with arguments but wanted to load the Javascript using the async keyword, so I assigned the arguments as global variables and access them when JS finishes loading. I found many ways to use SVG in this design, and I aggressively optimized the illustrations and the generated code. Editing the XML by hand can shave several kilobytes off the file. In one case, I reduced the file size from 40 KB to 4. I also use Grunt to pre-compress it as with the JS and CSS. If you're really obsessive, you can rearrange the SVG attributes for better compression. These may be basic tips for most of you, but I'm hoping they'll be helpful to someone. For anyone interested, I've attached the Gruntfile. I only ask that you don't judge the file structure too harshly. Since I probably haven't scratched the surface here, feel free to provide any of your own tips. gruntfile.js.txt

yeah but a little api magic can cure that.. open up your tools or api playground and: $pp = $pages->get(1234); // page you're adding the children to the page table foreach($pp->children as $child) { $pp->page_table_field->add($child); }

@Joss - using a super simple implementation now for docs, using admin custom pages and a nested accordion. obviously not as developed as your idea, but took about 20 minutes to setup and now this client can read the docs from their PW admin; screenshot: : *changed to single screenshot

Image Animated GIF v 2.0.2 Module for PW 2.5 stable or newer, but is obsolete for PW Versions greater then 3.0.89 (... read more ...) This module helps with resizing and cropping of animated GIFs when using the GD-Library. The GD-Library does not support this. This module is completely based upon the fantastic work of László Zsidi (http://www.gifs.hu/, builts the initial classes) xurei (https://github.com/xurei/GIFDecoder_optimized, enhanced the classes) I have ported it to a PW module and it works with core imagefields, together with Pia and with CropImagefields that uses the new naming scheme since PW 2.5. ------------------------------------------------------------------------------------------------------------------------------------------ read more in this post about the rewrite from version 1.0.0 to version 2.0.0 ------------------------------------------------------------------------------------------------------------------------------------------ You can find it in the modules directory: https://modules.processwire.com/modules/image-animated-gif/ and on Github: https://github.com/horst-n/ImageAnimatedGif ------ A preview can be found here

Thanks Adrian, you're great! I'll take a look at ImageRasterizer for sure, thanks for your advice.

Macrura, thanks for testing/using the module. The current master branch only uses WireData on object like structures and regular arrays for numeric key structures. I renamed the module to FieldtypeDataStructrue (because it now supports more than YAML) and have a separate repo for that, what you want is all there on the dev branch. Check it out, I added a bunch of features (including your wanted WireArray output and a couple of new input/structure types, beside YAML) and the whole thing is unit tested, so it SHOULD be pretty stable: https://github.com/owzim/FieldtypeDataStructure/tree/dev More detailed info on the new version: https://github.com/owzim/FieldtypeDataStructure/blob/dev/README.md For now you should create a new field and not change the fieldtype on your existing one to the new FieldtypeDataStructrue I think it now became pretty powerful, I am planning to make a video to cover it and all it's possible use cases. Please (all) share your thoughts on how else it could be used.

Have this in my bookmarks, never used it, but looks like it might come in handy for your needs. http://fontello.com/ It lets you pick the icons you need and export it as a web-font, you can even upload your or other icon fonts and use those

@tinacious: what do you get when you try: setlocale(LC_ALL, ($is_english ? 'en_US' : 'fr_FR.UTF-8'));

Hi everyone, Finally made some time to get the new module live. It is called Page Protector and you can find out more about it here: https://processwire.com/talk/topic/8387-page-protector/ Thanks to everyone who voted in the poll - based on the results, there will be two separate modules maintained: ProtectedMode and PageProtector. PageProtector can do everything that ProtectedMode can, so if you have a need for the features of PageProtector on a site, then there is no need to use ProtectedMode during development.

I am trying to put together my own icon set so I don't keep nicking everyone elses. So, these are primarily for use on a website - navigation, parts of the site, just a few social bits and so on. What others should I do? Without ending up doing hundreds! With companies, I am using their official logos, though not necessarily the right colours! For the moment I am just doing them in Illustrator in grey with no backgrounds. I will mess with them later and put them into neat sets. But these are my core images:

Have you seen this?: https://processwire.com/talk/topic/4131-difference-between-add-and-append/ - with the exact same topic title as yours... I also recall you've asked a similar question today here? https://processwire.com/talk/topic/6662-markup-cache-and-pw-performance/?p=81253 No need to double post..

Thanks for the file. The problem is that your SVG doesn't have width and height attributes in the SVG tag. PW uses these to determine the size of the image. Not sure how best to deal with missing attributes, but I'll have a think and chat with Ryan. In the meantime, if you add: width="1200px" height="500px" to the SVG tag in the file, you'll find that it uploads just fine. BTW, I am assuming you are familiar with SVG and know that they are easily editable with a text editor - and if not, now you know EDIT: Github issue submitted: https://github.com/ryancramerdesign/ProcessWire/issues/802

@Adrian: thanks for the feedback. Here she is a bit to modern I believe. I will change this soon!

That version should be fine. Would you mind attaching the image so I can test. Or PM it to me if you'd prefer.

SVGs definitely work and actually don't need to be resized by GD for the thumbnail. What version of PW are you running? There was a issue with SVGs for a while, but it is fixed now. Just for interest, here is the Github issue that describes when things broke and were subsequently fixed and improved: https://github.com/ryancramerdesign/ProcessWire/issues/597

Hey horst - looks awesome, but I am running php 5.3.28 on my dev server (just to pick up on things like this) and get a parse error due to: InputfieldRangeSlider::getModuleInfo()['version'] on line 345 Something like this takes care of it: if($modules->isInstalled('InputfieldRangeSlider')) $rangeSliderInfo = InputfieldRangeSlider::getModuleInfo(); $hasSlider = $modules->isInstalled('InputfieldRangeSlider') && version_compare($rangeSliderInfo['version'], '1.0.4', '>='); One minor typo while I think of it: here you can set sitewide options, - this overrides the options from site/config.php This is under the main config and also the advances section. As well as the missing "s", probably also don't need the comma and the hyphen.

Ryan, The new @ option in selectors saved me today. Just wanted to say thanks.

@Joss - yes, i'll post the complete instructions as a new thread in tutorials, and link to that here - would that be ok? here's a first draft... https://processwire.com/talk/topic/8392-simple-built-in-docs/?p=81303

cool.. this is all working great... will update my other post with the changes to the required code to output... as far as uses: - use a field for quickly importing child pages using structured data - use for editable settings (site settings, sliders, portfolios, other jquery plugins with a lot of parameters) thanks again for making this!

Manol, the plugin doesn't handle the deletion of the files in the assets folder. If the plugin is active, the files will be delivered through S3 without relying on the local ones , so theoretically you could manually delete them from you local assets folder but I think of it as a backup that you can quickly start using just by deactivating the plugin. EDIT: Sorry, I forgot to mention (too much work) that in the admin, the local files are used. So it's definitely not a good Idea.!

@Pete: regarding your "test.jpg", you only need to build a name that matches the new naming conventions of PW core Pageimage. That way all is fine because PW will do the dishes for you. It takes care of all image variations belonging to an original image. You only need to tell the system that this is a derivative image. The naming scheme now is aware of suffixes. You simply can use the original filename and add a suffix to it. (in fact it isn't limited to only one suffix, it can have multiple of them). Following the original image is named basename.ext If you want create one or more derivatives you should go with this scheme: basename.-suffix.ext basename.-suffix1-suffix2.ext following i change your above example in a detailed manner: // define suffix, and fileformat if needed $suffix = 'yoursuffix'; // allowed are: a-z 0-9 and underscore !! not more! $ext = 'png'; // your desired outputformat $image = $page->images->first(); // get the image $info = pathinfo($image->filename); $dir = $info['dirname']; // dir to the page assets/files/ folder $name = $info['filename']; // basename without extension $ext = $info['extension']; // only if you want use the same fileformat as the original is !! // build the targetfilename and the URL $targetFilename = $dir .'/'. $name .'-'. $suffix .'.'. $ext; $targetURL = dirname($image->url) .'/'. $name .'-'. $suffix .'.'. $ext; $sourceFilename = $dir .'/'. basename($image->getThumb('thumbname')); // Now do your nice manipulations if the image doesn't already exist (we only want to convert it once) if (!file_exists($targetFilename)) { $modules->get('PageImageManipulator')->imLoad($sourceFilename)->setOutputFormat($ext)->setTargetFilename($targetFilename)->save(); // or this way $modules->get('PageImageManipulator')->imLoad($sourceFilename)->setOptions(array('outputFormat'=>$ext, 'targetFilename'=>$targetFilename))->save(); } echo "<img src='{$targetURL}' />"; . . Additionally, if you use Pia to assist you while developing a site, your code should ask her if you are actually online and like to refresh all images: // Now do your nice manipulations if the image doesn't already exist or if you (Pete) are actually online, testing something and want force recreate images if (!file_exists($targetFilename) || true === $config->imageSizerOptions['forceNew']) { ... I love it when a plan comes together!

Once you register your domain with them, they crawl your server for elements that they can cache for you. I use CloudFlare, too, and it's very good. And the free account is exactly the right price!

I use fontello too, you can also easily create your own using SVG. I don't think it's a good idea for a non designer to make icons There's some lack of consistency and size/detail problems with your icons, they won't work small size etc.

Make sure domain B points to the same server (A record or CNAME) as domain A. And on the serverside you have to make sure that domain B it pointing to the same directory as domain A.

@Lance - I think you'll find that for the most part it is easiest to keep the pagetable pages as children of the page, but it will also depend a lot on your structure, and whether that page has children already, in which case put them somewhere else.. some examples of where i've use pagetables, and i think it will make sense: | Page | PageTable Children | |-----------|--------------------| | Album | Tracks | | Slide | Captions | | Portfolio | Images | | Vignettes | Vignette | i think if you use the reno theme and also lister pro, it actually won't matter that much where you put them; but in a lot of cases having them as children keeps things tidy and you can always get the relation of a pagetable item by calling it's parent. and you can add pages not through the page table, and it will pick them up and ask you if you want to add them. For PDFs, depending on the amount on one page, i might still consider good old repeaters

Nice one Adrian! Minor suggestion, maybe add a note/description to the setting 'Protect children' that the protection cascades to grandchildren, etc.

Horst, you had a long day?

Updated to version 4 - I had to fix the forceNew option what may be used during site develope. - also have changed a bit on the GUI: it detects if you have Fieldtype RangeSlider installed and uses that over a regular Integer Inputfield for Quality-Setting If you are already using it, please update too.

@horst, thank you for giving this some thought. I'll confess I did not follow all your listing. I think you're describing what is in the DB. What I'm describing is what is the admin user interface. I think you're concerned with the possible performance issues of injecting a module in the mix when you believe it's redundant. And you're concerned there will be a lack of transparency in the structure if some new meta data is introduced to control the shape of the tree. On the one hand, I like that the template collection can be very structured. It's a strength of PW. It reflects what the shape of the page tree can be. On the other hand, when I'm creating a new site, every time I need to insert a new type of object in the tree for the users to maintain, I have to create a container as well as the actual object of interest. The container is often very generic -- its ONLY purpose is to constraint the type(s) of children under it. Most of the time, it's a single child type (template) that is needed. When I need to modify templates, I have to exclude from my gaze the container ones. It "looks" messy to use. Also, when I set up a "container" for pages of a particular template, I usually don't want the user to change it. They might change the title(s), but that's about it. In those cases, a dedicated template instead of a generic one feels not "DRY". So, after I wrote my previous post, before reading your further thoughts, and still believing this isn't redundant, I went and built a simple module to deal with issue. I'm going to start using it for myself. I hope some find it useful. I hope I'm not trampling on some of the principles behind PW. I'll say it again, I think PW offers a fantastic model for building sites. Its "object tree" is brilliant in its simplicity and transparency for the user and the developer. And yet here, I think there's a hook missing. https://github.com/jeanrajotte/processwire_module_PageAllowedTemplate Looking forward to feedback. Thanks.

There are usually 2 menu types on most sites. Let me generalise here a bit. You've got the top navigation which tends to be global. It's on every page and usually accompanies the company logo. Then you've got the side navigation which is contextual or based on the section the user is currently within. I'm assuming you're asking how you your client can pick which links / pages are used on the top navigation? Create a field called top_navigation or something meaningful to you and your clients Set it to Type=Page type (Basics Tab) Make it Multiple Pages (Details Tab) Assign it PageListMultipleSelect+ win the Input field type (Input tab) Finally, associate this naviagtion field with a template. You can just assign it to the homepage or you could create a new page called Site Settings or Navigation. Just tell your client this is the place to manage their top menu. Here's a screengrab of how it should look.

I suggest that whatever you do you stay away from any fixed scaffolding framework. The point of ProcessWire is that people can use whatever layout structure they want. For instance, many like Bootstrap and Foundation as complete solutions, but many others find them large and cumbersome and too limited. If you have a large framework with lots of JS and CSS and then people want different JS for different slideshows or product display and so on, you can end up with an inflated beast. So, I would suggest you stick to the functionality in a very agnostic way and make sure it is done in such a way that people can create the template files it as they wish.

Is that a question??? You don't know what Ryan has under his sleeves. Fun times ahead.

Hello, PageTable is described as a leaner way to enter large amount of repeatable data into the admin backend, possibly with different sets of fields (think different templates). The main advantages compared to the Repeater are: 1. PageTable can save new pages where you tell it to. Repeaters are saved deep down the Admin pages and are given cryptic names. 2. One PageTable field can make use of several different templates. Repeaters play according to the "One repeater = one template" rule (roughly put). PageTable is a PageArray, so relevant methods are applicable. For example, here is how to add and remove items from a PageTable field using the PW API: // create a new page // IMPORTANT: your PageTable field must be configured to use template 'basic-page' in the field Setup tab $newpage = $pages->add('basic-page', '/about/', 'address', array('title' => 'Write to us')); $page->of(false); // add the newly created page to 'pt' which is a PageTable field $page->pt->add($newpage); $page->save(); Here is how to remove the first item from a PageTable field: $page->of(false); // 'pt' is a field of type PageTable $page->pt->get(0)->delete(); $page->save(); That's a quick overview of this new field type. Give it a bit of your attention, it's quite promising. Cheers, Valery.

Done 2 years ago PW 2.2-3 and it's still working.

Having run a couple of MODX Evolution sites in the past i can confirm that this system was/is pretty snappy on both the manager part and frontend rendering. I'm guessing that this is in part because of the relatively simple nature of the beast. Remember MODX Revolution? With it came more power but also backend performance and frontend rendering times took a dive. There is maybe another thing to consider, which you are probably aware of but maybe not. In Evolution, documents (think PW pages) are set to 'cacheable' by default. This means that all page output is cached. What was nice about the system was that, if needed, you could still call uncached snippets and such from within an otherwise cached document. But most of the times you would call snippets cached, i.e. without the exclamation mark. So in reality, in Evolution, most documents tend to be cached, either wholly or at least in part. So if you compare Evolution <--> PW with regards to total rendertime on the frontend (which is the only thing Google and end-users really care about) you should take caching into consideration for a fair comparison. Use template caching where possible and if not Markup Cache, at least for PHP/API/DB stuff. I see that with some use of Markup Cache you were already able to get within 200 ms of the comparable Evolution site. Maybe with Ryan's optimizations to the bootstrap this will only go down. That's pretty good if you ask me. Another thing to consider is that suboptimal use of the PW API in temlate files or other places and loaded modules can affect performance negatively. So be sure to scrutinize your PW projects for this stuff. In the end i think the power to performance ratio that PW delivers is pretty awesome!

@owzim, don't want to discourage you in any way, your doing great work here. Really enjoy seeing many others finally get more serious with module development, I know Ryan is, and I'm maybe just nit picking here. Yeah some good throughout documentation is a lot of work and I don't think I could pull it off. I did my contribution with the cheatsheet and that's already some work to keep it up to date, luckly enough it's now a ProcessWire site and can be managed some. With your module here while I don't understand all fully (haven't studied all nor installed yet), for example why you have config to the process module and on the textarea field (inputfield)? As per hook https://github.com/owzim/ProcessTextareaPreview/blob/dev/ProcessTextareaPreview.module#L120 Meanwhile you seem to have another config set in your process module too: public static function getModuleConfigInputfields(array $data) { return TextareaPreviewConfigHelper::renderForm($data, self::$defaultConfig); } But anyway, I think could that you're missing that the config is stored with the Field and not Inputfield? There's no storage for Inputfields, they're only for interface input and not DB. So like this you should get the custom data. $customFieldSettings = wire("fields")->get($inputfield->name)->customCssPath;

I hear with ravensburger you can have beautiful paintings on your wall too, some people will be satisfied with that. Other people prefer a Dali, da Vinci or van Gogh. I prefer a framework where i can decide how to do the things i want to build, not the other way around. ProcessWire gives me that freedom. Like Craig mentions i wouldnt knwo any project i build in the past two year or so where i would use Wordpress over ProcessWire

A few new/minor additions on the dev branch: You can now paginate with "limit=1" selectors. Previously ProcessWire didn't build the pagination information when a limit of 1 was specified. Now it does. ProcessWire now preloads pages that it knows it's going to need on every request. This speeds up everything slightly, as what was previously done in 6-7 queries is now done in one shot. Should you want to, you can also specify additional preloaded pages, though I don't think many (any?) would need to. Several optimizations to the PageFinder engine which improves the speed of certain types of queries. One of them is a $pages->count("selector") query, which is now even faster than before. Selector Grouping Added support for selector grouping to change the behavior of how they match. This is best explained by example. Lets say we're building a big news site, and we have a template called news-item that represents each news article. Each news-item page has a field called cats that is a multi-page reference to one or more category pages. This is a pretty common scenario in ProcessWire. The site has a lot of categories, so want to designate some categories as featured so that we can display featured categories on the homepage and elsewhere, with accompanying news items. Rather than just adding a featured checkbox, we add two fields to represent the date range that we want them featured: featured_from and featured_to. On our homepage, we want to display articles from all the current featured categories, so we build a selector like this: $items = $pages->find("cats.featured_from<today, cats.featured_to>=today, sort=-date"); ...but we end up with more news-items than we expect, including some that have categories that aren't actually featured right now. Why? Because each news-item can have multiple categories, and that selector above is saying this: The keywords there are "at least one", as "categories.featured_from" and "categories.featured_to" may not be referring to the same category. The only way to solve it was this: $categories = $pages->find("template=category, featured_from<today, featured_to>=today"); $items = $pages->find("categories=$categories, sort=-date"); That's easy enough... but now you can also do it like this, by prepending an @ to identify a group: $items = $pages->find("@cats.featured_from<today, @cats.featured_to>=today, sort=-date"); The "@" symbol at the beginning of "cats" is telling ProcessWire those are grouped together and "these must match the same exact page". This was added because there are situations where you need to perform your query with 1 selector rather than breaking it up. An example would be when used with the new InputfieldSelector module and Lister, among others. We will likely be adding more ways to perform complex matching scenarios with a single selector as well. Currently this "@" grouping applies only to multi-page reference fields, as I'm not sure yet where else it might be useful. It is only supported by selectors that hit the database at present (though will be completing it for in memory selectors as well). Not planning to extend it into that area at this time, but good ideas to think about for the future or for modules. It should already be fixed. If we're talking about the same thing, someone recently posted this to the GitHub issues list and I added their fix on dev. Adrian already knows this because we've been chatting in the GitHub issues queue, but for anyone else reading this, it has also been fixed.

You can't do this just out of the box but with a autoload module you could easily accomplish this. Also there's useful needed features in there for an editor. Why is this a problem? It may not necessary in most cases... In PW, almost all of these things can be changed modified using hooks on what builds them in the admin. So if you really want to do it, the best way would be through a module like the /site/modules/HelloWorld.module It shows some example of hooks and is worth a look and have a play anyway. This following module hides the InputfieldWrapper "Who can access this page"? in the settings tab for user having a role "editor". <?php class AdminHelperHooks extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'My Admin Helper Hooks', 'version' => 1, 'singular' => true, 'autoload' => true ); } public function init() { // add hook to the page edit module and the method that creates the wanted fieldset $this->addHookAfter('ProcessPageEdit::buildFormRoles', $this, "removeSettings"); } function removeSettings(HookEvent $event){ // check what role the user has, if not has editor role do nothing if(!wire("user")->hasRole("editor")) return; // $event->return being the inputfield wrapper $wrapper = $event->return; // set the inputfield wrapper to hidden $wrapper->collapsed = Inputfield::collapsedHidden; // we're done } } Create a new file AdminHelperHooks.module with this code in a new folder /site/modules/AdminHelperHooks/ Install and test with editor user.

Your first step (assuming you are talking about a photo gallery here) is to output the gallery as normal. There are some ideas on how to do that in this topic: Then you would implement that jQuery code as per the instructions on their site I imagine, but the first step is always getting the basics sorted in your template first and then adding in things like this after that's set up.