Leaderboard

Hello everybody, I'd like to introduce a new module to you. It automatically adjusts pages' URLs based on naming patterns. It allows you to specify a general pattern for all pages or individual patterns per template. It is available in the ProcessWire module directory. Also you may find the code here. New: Auto Name has been updated to Version 1.1. Changes: It is now possible to set a human-readable date format for the created and updated fields Renaming can now be restricted to unpublished pages Includes a fix for a bug that accidentally renamed system pages I'm looking forward to your feedback. Thanks in advance, Marvin

It is quite some time since I wrote tutorials in the wiki and I am starting the task of updating them and putting the new versions in the tutorial section of the main website. To kick things off, here is a brand new, created from the bottom up, Simple Website Tutorial https://processwire.com/docs/tutorials/simple-website-tutorials/ It is aimed at new users who are comfortable with HTML and CSS and have some limited, basic php knowledge. This is different from the very basic tutorials I have been writing aimed at those who know no php at all and have no coding skills. Like the old series, this constructs a website, complete with html and then further tutorials will use this as a basis. Joss

If you go the route of importing your data with the API and an install script it's worth mentioning that you can restore your system easily while developing you install script. So make a backup before, via $database->backups()->backup(); An in your script at the beginning, add a $database->backups()->restore("filename"); So each time it runs, you have a fresh version you can hack on, without having to clean up manually each time you mess up something. More details here: https://processwire.com/blog/posts/august-2014-core-updates-4/ I think it's very convenient =) Of course you have to remove the restore call when you're finished with your script. Additionally since PW 2.5.4 (yesterday) you can pass arrays to InputfieldWrapper, InputfieldForm, or InputfieldFieldset which makes creating the necessary templates and respective fields for your imported data very easy and fast. See at the bottom: https://processwire.com/blog/posts/new-module-configuration-options/ https://processwire.com/blog/posts/august-2014-core-updates-4/

Regarding the backup and restore option that owzim mentions. It is indeed very cool, but there's a bit of a problem with it at the moment. Any new fields that get created by your import script won't have the DB table removed when you run the restore which will result in table already exists errors when you run the script again after the restore because the field has been removed from the fields table so PW doesn't know about it anymore, but it's field_fieldname table is still there. Hopefully Ryan will sort out a fix for this shortly. Of course if your import script isn't creating new fields (or anything else that adds a DB table to PW), then this won't be an issue.

Some more bug fixes - thanks again to muzzer! More interestingly though, during import you now have the option to automatically download and install any required missing fieldtypes/inputfields from the PW modules directory. This is optional and I have noted that if you don't trust the source of the data you are importing, then you might want not want to enable this option. It is off by default, in which case you'll receive notifications of what's missing so you can install manually before re-starting the import.

Given all the ex MODx'ers around here, I would love to see a plugin for Migrator. If you're willing to give it a go, Nico's Worpdress Migrator plugin for Migrator (that teppo mentions) might get you started. Is there an existing MODx to XML/CSV/JSON tool available that could be used as a starting point?

FrontendContentManager (unstable / testing) FrontendContentManager is a module based on FormHelper to generate needed page edit / add form via form api. NO sanitizing of form values at the moment!!! edit pages create / add new pages add, replace and remove images Download ProcessWire module page: http://modules.processwire.com/modules/frontend-content-manager Bitbucket Repo: https://bitbucket.org/pwFoo/frontendcontentmanager Version 0.2.0 Required FormHelper (0.7.1+) Usage Example template file <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title><?php echo $page->title; ?></title> <?php // Load FormHelper module and also set wire('fh') variable $fcm = $modules->get('FrontendContentManager'); // edit existing page //$form = $fcm->edit($pages->get('1108')); // add a new page based on a template and a parent object $parent = $pages->get('name=test'); $form = $fcm->add($parent, $parent->template); // jsConfig needed by ckeditor echo $fcm->JsConfig(); // outpunt needed scripts for inputfield modules, ... foreach ($config->styles as $file) { echo "<link type='text/css' href='$file' rel='stylesheet' />\n"; } foreach ($config->scripts as $file) { echo "<script type='text/javascript' src='$file'></script>\n"; } ?> </head> <body> <h1><?php echo $page->title; ?></h1> <?php // output the forom echo $form; ?> </body> </html> *UPDATED TO 0.1.0* At the moment I have no usage for FCM module, but after FormHelper 0.5.2 is finished I've done a quick FCM rewrite. Only few tests done yet! *UPDATED TO 0.2.0* Updated to work with redesigned FormHelper 0.7

Actually FieldtypeComments already has built in support for Gravatar. Never tried it though and don't know how to use it. I have looked at the code but can't figure this out. I also don't have a Gravatar account so can't test anyway. Anybody knows how to use this and willing to help us out with this? Hopefully Ryan will also see this. Thanks.

And if you want to avoid messing with core files try using Martijn's awesome Admin Custom Files (http://modules.processwire.com/modules/admin-custom-files/) to add that CSS.

Makes sense, but what happens if they aren't logged in and there is no cookie set ? One thing I just noticed - if the user is logged in, you set $me to the user object and not it's id, so when you do myrank($me), it won't work! myrank($score_me) should work in both cases though.

I don't but any of the PW hackers here should. What irritated me, is that with the Twig replace module everything works as expected, for which a reason should exist, so I looked into the code, and not only is the Twig replace module hooking into PageRender::renderPage instead of Page::render (as suggested in my GitHub issue) but also the vars are explicitly collected and passed, see https://github.com/marcostoll/processwire-template-twig-replace/blob/master/TemplateTwigReplace.module#L216 $twigVars = $this->collectVariables($page->output); $output = $this->getTwig()->render($page->template->name . '.' . wire('config')->templateExtension, $twigVars); So perhaps the right path would be to actually replace the render method with the same hook as above and load the respective template file and the TemplateFile class. The downside of it (and I think it's the same with Twig replace module) that the render method must be held in sync with the core version (appending, and prepending files like _init.php and such, and also the new template specific append/prepend functionality since 2.5). I am not too much into the topic so I might just be guessing here. Dear PW hackers come one, come all. PS/OT: this forum should support MarkDown, post authoring/editing in here is a bloody mess.

First of all, you really shouldn't try to do an import via phpMyAdmin. Using ProcessWire's API is always a better (and easier) way. Direct SQL import is going to be a lot of work and might cause all sorts of unexpected issues, some of which you might not notice until it's too late. Import scripts are easy to write -- usually the hardest part is getting data out of the other system and, of course, planning your new data structure. I'm not familiar enough with MODX to know how easy or hard it's going to get data from there, though, but I've done my fair share of import scripts for other systems. Usually the easiest method is exporting data from original system as CSV, JSON or something else that's "machine readable" and then writing a simple import script using the bootstrap method, but there are other methods too. You might want to check out this case story -- and perhaps ask some questions in that thread too -- as it seems to have some similarities with your case. Also, if you can get your data out in CSV format and it's not too complex in structure, Import Pages CSV just might do most of the work for you. Migrator tool built by Adrian is somewhat related too, though that's not exactly off-the-shelf solution for this particular situation (there's a WordPress migrator available, but not one for MODX yet, at least as far as I know). Hope this helps a bit.

Overview Mobile Detect uses a lightweight PHP class Mobile_Detect for detecting mobile devices (including tablets). Installation 1a. Clone the module and place MobileDetect in your site/modules/ directory. [OR] 1b. Download it. git clone https://github.com/justonestep/processwire-mobiledetect.git your/path/site/modules/MobileDetect 2. Login to ProcessWire admin and click Modules. 3. Click "Check for new modules". 4. Click "install" next to the new SimpleContactForm module. Usage This Module extends $config and sets the following parameters: $config->mobileDetect = array( 'deviceType' => 'deviceType (phone, tablet or desktop)', 'browser' => 'mobile browser', 'operatingsystem' => 'mobile operatingsystem', 'device' => 'mobile device' ); You can access them where ever you want. See the example below: <body class="devicetype--<?php echo $config->mobileDetect->deviceType?>"> <body class="devicetype--{{config.mobileDetect.deviceType}}"> // twig Results in: <body class="devicetype--phone"> OR<body class="devicetype--tablet"> OR<body class="devicetype--desktop">

FormHelper The redesigned FormHelper extends the InputfieldForm object with additional features. Features The FormHelper module extends the PW form object and simplifies the form handling. create basic PW form object with submit button add form field value handling and sanitizing take care about form submit / error state and processing CKEditor pwImagePlugin field, jsConfig, load form admin styles FormHelperExtra is a submodule to handle additional features. create a form object with fields based on Template, Page, Form objects or field data array form file upload handling (temp page uploads, creation of a hidden storage page) Usage Documentation / examples Repository PW module repo GIT repo ToDo / Issues Issues

This is a very basic guide on how to optimize a ProcessWire page for speed. It doesn’t go into the depths of optimization and perfect render paths but will provide you with some proven ProcessWire methods for faster websites. The big problems that are easy to fix are what we aim for. You want quick improvements? Then read on… First let's have a look ath the following graph. Those are the areas, we want to improve. Source: http://httparchive.org/interesting.php?a=All&l=Oct%201%202014 Clean up your HTML Look at your HTML source code. Are there any unnecessary parts? Remove anything that might not be needed and try to keep your markup as clean as possible. Avoid using too many external JS libraries or other tools. It is okay to include jQuery from a CDN, because most visitors will already have cached the file. Too many of those external requests will slow down the page. If possible, try to avoid render-blocking Javascripts and move your script tags to the end of the page, right before the body. In most cases, your Javascript will enhance your content but doesn’t need to fire before the site is rendered. Always think if you need to include another library or the fourth webfont on your site. Minify Markup The next step to save some bytes is to remove all whitespaces from your markup. It doesn’t have to look nice, it has to be loaded fast. We perform this trick with our new super-weapon: The AllInOneMinify module for ProcessWire. Install it like every other module for ProcessWire. Once activated, go to the module settings and tick the checkbox for “Minify HTML” and look at your sites source code. It should be minified. AIOM can handle conditional browser comments. If your layout depends on whitespaces you could “force” them by putting an into the markup. Optimize the CSS Now we’re heading for the next larger part of a usual website. We will combine all CSS files and then remove anything not needed (whitespace,comments) from it. Before we start, make sure your CSS files only contain rules that you really use. Especially if you’re using a framework like Bootstrap, most of the selectors are never used. Remove them carefully. We need the AllIneOneMinify module from the previous step again. After installation, open the template file where your HTML header is generated. We will now replace all stylesheet tags with a single file. AIOM needs to know all CSS (or even LESS) files, relative to your template folder. It will then output a link to a single, compressed CSS file. You might have this in your HTML head: <link href="<? echo $config->urls->templates;?>/css/grid.css "rel="stylesheet" /> <link href="<? echo $config->urls->templates;?>/css/style.css“ rel="stylesheet" /> Replace all links to Stylesheets with the single tag like this: <link href=”<? echo AIOM::CSS(array(‘css/grid.css’,’css/style.css’)));?>” rel=”stylesheet”/> You pass an array with the file names to the AIOM method CSS. It will return a link to the file. AIOM takes care of image urls inside CSS. It will detect changes in the source file and only generate a new file if necessary. While developing, you might want to turn on the “Development” checkbox in the module settings. Make JavaScript tiny Do the same as you do to the CSS to your Javascript files. First, clean up the code. Then install AIOM and compress all JS files into a single file using the AIOM::JS method that works as the AIOM::CSS method. For best results, think about including scripts like jQuery from a CDN and put your scripts below the content, before you close the body tag. Also note that the order on how your throw your JS files into AIOM might be important, depending on the code inside. Get the right image size. ProcessWire comes with great image tools. Use them, to make images exactly the size you need them. You don’t have to serve that little thumbnail with over 3000px length just because the editor wasn’t able to reduce the size. Example: Your designer wants to have a slider image with a maximum size of 600x320 pixel. To output the image with that exact dimensions, use the API accordingly: $sliderImage->size(600,320)->url; An even better way would be to use adaptive images or the new srcset attribute combined with a JS fallback. Then your site only delivers the image size as needed. Hint: Play around with the image quality setting in the config.php. Maybe you don’t need images with a JPG quality of 90+. Compress the images further with minimize.pw To make images even smaller, we can use the minimize.pw service. This service will compress images nearly lossless by using more complicated tools to reduce the size of PNGs and JPEGs. By doing this, you remove bytes from the largest chunk of your website weight. minimize.pw is free for 2000 images. Just enter your E-Mailadress and receive a free key Then you have to install the ProcessImageMinimize module and enter they key. You can now activate the option to automatically compress every image uploaded. It is fail-safe and will compress images in the background. Please note, the automatic mode only works with images uploaded AFTER you have activated the module. You can manually select image fields with the ->mz() API method. Just include it before you output the image in your template file: $myImage->width(300,300)->mz()->url; We've closed the service. You could use something similar like Imgix ( https://www.imgix.com/ ). Activate GZip compression on your site Another method to speed up your site is to activate GZip compression. The server will then send all files compressed to the client. This works with nearly all browsers and the CPU power required is minimal. You can tell your server to do this, by adding those lines to your .htaccess file in your root directory. Please take care, that you do not overwrite the ProcessWire rules in the file! For best results add them on the top of the .htaccess file: <IfModule mod_deflate.c> AddOutputFilter DEFLATE js css AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html </IfModule> This was taken from another forum post. Tell the client to cache stuff To make repeating visits faster, we can tell the browser to cache special files for a longer period of time. Again, add this on top of your .htaccess file: <IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 1 seconds" ExpiresByType image/x-icon "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType image/png "access plus 1 year" ExpiresByType image/gif "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType text/javascript "access plus 1 month" ExpiresByType application/octet-stream "access plus 1 month" ExpiresByType application/x-javascript "access plus 1 month" </IfModule> <IfModule mod_headers.c> <FilesMatch "\\.(ico|jpe?g|png|gif|swf|woff)$"> Header set Cache-Control "max-age=31536000, public" </FilesMatch> <FilesMatch "\\.(css)$"> Header set Cache-Control "max-age=2692000, public" </FilesMatch> <FilesMatch "\\.(js)$"> Header set Cache-Control "max-age=2692000, private" </FilesMatch> <FilesMatch "\.(js|css|xml|gz)$"> Header append Vary: Accept-Encoding </FilesMatch> Header unset ETag Header append Cache-Control "public" </IfModule> Remember, that this caching might be annoying while developing the site. Use the internal cache (or ProCache) Another trick to make the site faster is to use a caching system. This will “store” your rendered site so you don’t have to query the database that often. We can either do this with the internal cache of ProcessWire or use the commercial, official ProCache module. Using the build-in system, you go the the setting page of a template and open the “Cache” register. You can now set the Cache time and what happens if something changes. The settings depend on the content of the site. Mostly static content can be cached longer and you might not need to reset the cache every time. Dynamic sites will need shorter cache times. ProCache (buy here) is even faster because it will bypass PHP and the database. Files are served directly as HTML. Please note, that caching might make the site faster but it can create new problems. Use with care. Summary Keep your code as clean as possible. Remove anything unnecessary and then compress HTML,CSS and JS using the AIOM module. The largest part of your page weight are images. Keep them small by using the appropriate dimensions and consider services like minimize.pw. In the end, use intelligent caching and buy ProCache. Following this guide takes not more than an hour but can speed up your site and make your visitors happy. This was just a quick overview of techniques to optimize your page speed. There is plenty of stuff you can do but the steps above are a good first step. Maybe you can share your favorite methods (or links) to start the discussion.

FrontendUserLogin Module to handle frontend user login / logout. Also should work with Persistent login for users (mode: automatically) out of the box Version 0.3.1Requires PW 2.5.5 (fields defined by array) Download Processwire module page: http://modules.processwire.com/modules/frontend-user-login/ Bitbucket Repo: https://bitbucket.org/pwFoo/frontenduserlogin/ Usage Readme file Module isn't available anymore, but it's planed to replace FrontendUserLogin and FrontendUserRegister with the new FrontendUser module which is not released yet. A new support topic will be created after FrontendUser module is added to the PW module repo. FrontendUser module

Hello, I think it would be fun to nickname the Processwire versions like the mayor softwares (Wordpress, Ubuntu, Mac, etc). So I propose that versions should be nicknamed after scientists/inventors or cool people that make experiments because Processwire "ancestor" Dictator CMS was named after the Thomas Alba Edision's Dictator Machine. Also, nicknames could come from beer, wine or fantasy characters like Bilbo Baggins or Gandalf?. What do you think?

MarkupAdaptive This module aims to be a helper for developing an adaptive site. MarkupAdaptive is a module that injects classnames representing 'media queries'. Fire events after the browser is resized and fires an event when a media query is changed. Optionally it can write a cookie with the ‘media query’ classname of the current viewport size. The main purpose of this module is about syncing media queries with javascript. Say I want to have a slider on the iPad but don't want that slider on the phone I could now destroy the slider exactly on the right time. You could respond server side with this cookie, but keep in mind that you then need a workaround for the default caching solutions. (template cache or ProCache) The module script works with injected media queries and a HTML element tested against those. This javascript process starts real early in the load process and is extremely fast. It starts even before the body tag is parsed. In Explorer 7 and 8 clientWidth is used to pinpoint the “classname of the viewport size”. To support Explorer 7 and 8 your media queries should be specified in pixels. In the wild An working example of the module is hosted on hosted on lightning.pw Instant ProcessWire Hosting from conclurer.com. Please don't forget to view the console.log(). The site doesn't use any media query in the stylesheet. Not that I recommend building adaptive sites without media queries. . How to install Install the module At least open the Module configuration, optionally save it. Insert the below code in the HEAD of your html file <script><?php echo $modules->get('MarkupAdaptive'); ?></script> Javascript methods available when using MarkupAdaptive. ( More instructions like Event support IE7 & 8 are available in the 'example template' packed in the module folder ) /** * Getting information with Javascript. * */ // How to catch the end of a resize (with jQuery) $('html').on('resized', function(e) { console.log('Browser window is resized'); }); // Respond on a media query change $('html').on('mediaquerychange', function(e) { // Get the old class name before the “mediaquery” change has occurred var oldClass = MarkupAdaptive.getOldClass(); // Get the new class belonging to the current “mediaquery” var newClass = MarkupAdaptive.getClass(); console.log('mediaquerychange, from: “' + oldClass + '” to: “' + newClass + '”'); }); // Get the current class var current = MarkupAdaptive.getClass() // Get the old class, the class before the current var old_class = MarkupAdaptive.getOldClass() // Mediaquery JSON object which originates from your Modules config var sizes_object = MarkupAdaptive.getJson() // Mediaquery JSON object which originates from your Modules config' var array_with_classnames =MarkupAdaptive.getArray(); // Is the current browser IE8 (returns true/false) MarkupAdaptive.isIE() // (bool) // Is the current browser IE8 MarkupAdaptive.isIE(8) // (bool) // Is the current browser less then or equal to IE9 (lt, lte, gt, gte) MarkupAdaptive.isIE(9, 'lte') // (bool) // get the cookie, when checked in the module configuration function getCookie(name) { var match = document.cookie.match(RegExp('(?:^|;\\s*)' + name + '=([^;]*)')); return match ? match[1] : null; } console.log('Classname cookie value: ' + getCookie('MarkupAdaptive')); Special thanks to all the people from conclurer who made it possible to host MarkupAdaptive. When you're searching a lightning fast hoster. You should consider lightning.pw. View on GitHub Download GitHub

Actually if you look at the code in Timestamp.php, lines 40-47, that is where the conversation from string to integer happens so you don't have to do this in your foreach; Providing a date string is enough . if($key == 'date') { // convert date string to unix timestamp if($value && !ctype_digit("$value")) $value = strtotime($value); // sanitized date value is always an integer $value = (int) $value; } See also the comment in FieldtypeTimestamps.module lines 140-1 Also never got the errors you were getting. But I suppose your implementation of the code is different so I may be way off here... Btw, about your earlier questions on how stuff was getting deleted in the backend? The module is using trackChanges. You can read more here about the method. Edit: Aaah, I think I now see why you were getting that PHP notice. As pointed out in the SO link you gave, date() expects the second parameter to be an integer. In the case of InputfieldTimestamps.module, it's getting its values from the database. Those values were already saved as integers so no need for strtotime at that point. In your case, your values are coming from your frontend form as strings so they needed to be parsed into timestamps. At least I think this is what was happening. Anyway, you sorted it out but just thought to clarify this. Or maybe, I am not getting what's going on....I am having one of those slow days...again...sigh...

Hey owzim, this is exactly the reason why i don't want to completely replace the render method (plus i honestly don't know what would happen if the method is replaced not only by one but several modules). I'll start a thread asking if it's possible to make the variables persistent in the module development board.

Hi Marvin, I love it, although I am surprised you got a like from Antti on this, given his dislike for changing the url after the page has already been created I wonder if it might be nice to have an option to determine whether the rename will happen only the first time the page is created, or if it can change every time the page is saved (the current behavior). Just a thought - if you could check to see if my PageRenameOptions module is installed and check its settings to see what behavior is selected and honor that ? Just an aside - your module seems to works quite nicely with my Redirect IDs module. If there was a setting in your module to prevent subsequent renames, Redirect IDs could ensure redirects work so long as they use something like "id title" in your config settings. I know PagePathHistory would also be effective. Just exploring all the different options we now have

Calling AIOM/chmod experts... Just today a whole website of mine using AIOM ceased to function. Precicely 1 month after installing AIOM on the site, I was getting a 500 error. Looking at the PW log file I saw countless repetitions of... 2014-10-18 15:59:18 guest http://***.com/?/ Error: Exception: The permissions (chmod) to delete old cache files could not be changed. (in /srv/***/www/***.com/public_html/site/modules/AllInOneMinify/AllInOneMinify.module line 646) So, I guess one or more of my cached files had hit a 30 day expiry date. I did a bit of investigating, and it seems that before deleting cache files, AIOM like to chmod 777 the file. If it can't chmod the file, it throws this error and stops the site loading. No logging into PW admin, nothing. It seems similar to this problem here: https://github.com/ryancramerdesign/ProcessWire/issues/648 And the exact line of code in question is highlighted by Ryan there. https://github.com/FlipZoomMedia/ProcessWire-AIOM-All-In-One-Minify/blob/AIOM%2B/AllInOneMinify.module#L641... It's line 646. Is there any real need to change the permissions to 777 before deleting? The problem in my case is that www-data doesn't own these files. I copied this installation over from another server, and the owner (chown) is actuall "admin". But I have group rw permission to www-data, so the files can be deleted. I think that should be okay, right? So, what I did was comment line 646 and added the following three lines // ------------------------------------------------------------------------ // Remove all files that are older than the maximum lifetime. // ------------------------------------------------------------------------ foreach ($_cacheFiles as $_cacheFile) { if (((filemtime(wire('config')->paths->assets.self::$cacheDir.DIRECTORY_SEPARATOR.$_cacheFile->getFilename()) + self::$cacheMaxLifetime) < time() OR $force_all === true) AND is_file($_cacheFile)) { $_file = wire('config')->paths->assets.self::$cacheDir.DIRECTORY_SEPARATOR.$_cacheFile->getFilename(); if(chmod($_file, 0777) !== false) { if(unlink($_file) === false) { throw new WireException('The old cache files could not be deleted.'); } } else { // throw new WireException('The permissions (chmod) to delete old cache files could not be changed.'); if(unlink($_file) === false) { throw new WireException('The old cache files could not be deleted.'); } } } } And now everything seems to work again. Stuff like this sort of scares me. The last thing I want is for sites to completely and arbitrarily stop working!

GOOD POINT! SOLV3ED

Head explodes.

Thanks for this Steve. I've been cheating and changing the names via JS - which is clumsy at best.

Now I see.. Thats dirty Great you've solved this Steve ! Thanks about the issue rapport !

Hey owzim. I'm glad you like the module. We're still using it in all of our projects (but as I've already mentioned combined with TemplateTwigReplace) so it has to be maintained further even if it's only for our own projects. I'll look into this issue and try to do my best in the next days. Sadly marco (who is a great software engineer - a lot better than me) isn't working for neuwaerts anymore but if I can't resolve this issue by myself I'm sure he'll help us fix it.

So, should we made a Poll? Why not we take names from architects and inventors and choose by a democratic vote? xdd some Inventors that comes to my mind are: Nikola Tesla ~> Processwire 2.5 'Tesla' Isaac Newton ~> Processwire 2.5 'Newton' Albert Einstein ~> Processwire 2.5 'Einstein' ?? I do not know many architects though

Ryan does like his beer

I think it is terribly easy to clutter up a ProcessWire installation with a huge amount of information. One thing that is important to remember is that ProcessWire is not WordPress and is not aimed at the casual blogger with little knowledge hitting an install button on their CPanel. ProcessWire is a true CMS in that it is a system that manages content - whatever that content is. Because it is agnostic about the nature of the content, by nature it requires a certain amount of development input post installation - in other words, its strength is that it does not try and force you down a certain route. Consequently, it really is a development CMS, even though it is incredibly easy to learn even for non-developers. So, I agree with Diogo just above that all that is required is links to useful tutorials and for the actual installation to be as clean as possible. As an additional note, I would like to see a way of reverting the installation to a clean state. So, for instance, you can install with demo content, or maybe a third party tutorial profile, but once you have finished, you can press a destructive button to "install clean profile." This effectively removes all trace of the existing profile, wipes the database (keeping the admin user details) and gets you back to a blank install. This button would, of course, need to be available as part of the disposable profiles and not there by default! Would not want any accidents......

Interesting discussion! I definitely think Processwire could improve its usability but I don't think plugins is the way to do it. I just did a clean install of PW 2.5 and documented each step in the process. Here's a .pdf with 44 slides that covers the scenario of a new user's first contact with PW: http://cl.ly/0e3V2M3w1z1B ​comments appreciated

Thanks OrganizedFellow, Learning new things is core to human nature. When you stop learning, you'll become depressive. ps, That OrganizedFellow is really organised. (I saw his bookmarks:-)) We know he invested in learning, he succeeded. It's a pleasure to have him here.

I've been a member here since July 2012. I have less than 300 posts. If you were to check them all out, I am mostly voicing my opinion. Very very very few of my posts are CODE related. I don't share code with someone in the hopes it works for them because it worked for me. I don't post code issues that are not working on my installation. I AM NOT A CODER. Period! ADHD and OCD make it incredibly tough to piece things together. I don't memorize every CSS3 element or attribute. I rely heavily on http://www.css3.info/ and http://caniuse.com/ I don't dare memorize much PHP either, so I shoot over to http://php.net/ I use Foundation5 for my layouts, but I can NOT memorize those damned classes, so http://foundation.zurb.com/docs/components/grid.html All I know is the basics: git status, git add ., git commit -m'This is my commit message.' For ANYTHING ELSE I Google the hell out of it. For others, I rely on the above bookmarks, or the other 1,000 others I have bookmarked here on the forums of snippets and little code ideas that could come in handy. Have I learned PHP? Yeah! I can create some variables, if and elseif statements, and simple loops. With my limited PHP, HTML5, CSS3, and Foundation5 knowledge. I've put out several websites this year. Made $x,xxx. Made some hardware upgrades. Bought some business cards. Purchased the PW Forms module. Taken my family out to dinner. I've learned that if I want to make ProcessWire do this and that, which it CAN'T do outta the box - I got a little bit of learning to do. AND I AM NOT A CODER! hah!

Believe it or not but this is the only php that you have to know (already discussed before) to make websites with processwire: 1. href="<?php echo $config->urls->templates?>styles/your_css_style.css" /> 2. src="<?php echo $config->urls->templates?>scripts/your_java_script.js"> 3. <?php echo $page->your_field; ?> 4. foreach echo "html and code"; All the rest is your own html and css to make it as beautiful or interesting as you want. So it's actually 4 php things a beginner has to know and there isn't much to learn here just follow a simple format, that is all. From there you can simply grow into php as far as your website really needs more php.

First: I think such thing is easy possible with the upcoming 2.5 that have a import/export for fields: https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes/page-6#entry68899 So such examples could get some demofiles.... Second: I find PW is for me a educational system!! Really like this aspect maybe we should advertice this on the homepage!! This is the reason while users are here (and i'm so happy to found it) i can reinvent the wheel i like - i coun't do that with any other cms - and serve my clients with the result that i believe it's good. So please argos and norbert take a breath, read the letters from the experienced users here and accept there strong opinion - there is no fear, there is no need... @Joss - could the old wiki entries that are mostly complete transformed in some tuts....wiki is badly linked (i found it via some older posts) but they helped me very much to get first results special this four would be great: http://wiki.processwire.com/index.php/Small_Project_Walkthrough http://wiki.processwire.com/index.php/Basic_Website_Tutorial http://wiki.processwire.com/index.php/Simple_Gallery_System http://wiki.processwire.com/index.php/Simple_News_System or link it in the docs for now?

I think this is the problem, the catering bit. PW is a one man company with a small group of talented and helpful contributors. The current situation is that there is just enough people to manage and support PW as it is. If it grew a complex layer on top of the existing system that would need to be monitored, continually updated and so on, then it would quickly become unmanageable. One of the reasons that there are so many CMS type system out there full of bugs (especially plugins) and have huge maintenance issues is because they grew beyond the ability of the original developers to control and maintain properly. In that way, growth does not add value, indeed it can undermine it. As several of us have said, the profile system allows for variants to be created that can be installed as part of the main installation. So, if some users want to create a profile that offers the same sort of plug and play features as WordPress or Joomla, then that is by far the better way to do it than to expect the core maintainers to do it and in the process risk the integrity and maintainability of the system as it stands now. Really, this is nothing to do with what CAN be added to ProcessWire in the way of additional functionality - we all know that anything is possible - really this is about WHO adds all that functionality and who has the time to maintain it properly: if even just a thousand people use that sort of system and want support, then that is a full time job on its own.

It's been a while that I used ProcessWire to build a 'regular' website. (Not that I really know what a regular website is). Recently I finished a planboard system for managing newsletters and placing banners for multiple Portals. At home I have a personal little project a Ajax driven website for a band (Friends of mine). So my context of 'improving usability' is expanding API capabilities. The devs here do understand really well that there are many use cases for ProcessWire. The sky is the limit, and beyond. You have to know that ProcessWire thrives on good will of the community. It probably only takes 1 man to stand up and start building a commercial themes download website. This theme-able profile should have some standards. So that there are plug-ins that are interchange-able. This all can be done with PW, because of the power of the API. This discussion is a really good discussion so we're all glad that these stories come up.

@argos Here is a prezzie for you: How to create a gallery without getting bogged down by someone else's module: https://processwire.com/docs/tutorials/galleries-short-and-long/ Brand new, I just wrote it while drinking my coffee.

@argos, great to hear that. I would feel a bit responsible if you would have the opposite reaction and give up on PW and on us... But, if you say you feel that you are getting behind and frustrated for not being able to implement your ideas, I would say that you arrived to PW at the right time. Go through the tutorial calmly, don't hurry. Start with replacing the content in your html by simple PHP like <?=$page->body?> and ignore all the complex stuff that people write in the forums some times, later you will understand them. Don't jump to the cheatsheet without first reading the API Docs. Read why Ryan decided not to use {{these kind of tags}} and use pure PHP instead. Give yourself time to learn something that you feel you needed for some time. By the time you will feel comfortable with PW, you will realize that you also know PHP. Oh the joy --- As I said, I understand the need of discussing the tool and also the way that it sells itself to people. But it's how the core of PW is structured that makes it such a flexible tool. Changing the way it works would start removing that flexibility and make it become heavier and heavier. It's what people will do with PW that will make it grow stronger and directed towards other publics, not as it's core, but as the tool behind each of those applications. Couldn't be closer to the truth! PW is a very friendly CMS to those that will use it as a content management system, your clients, and is a powerful tool for you, the developer, to make sure that they will get the absolute best experience. EDIT: totoff was faster

CMSs make hand coding by editors obsolete (as it was usual in the ancient times), thus allowing content to be published quickly and easy. That's what I understand from this sentence. I don't understand, that CMSs allow to build web applications (sites, apps) without coding skills. Even WP requires coding skills if you want to take it one step further (in fact, it requires much more coding skills than PW does ...) .

I personally would not welcome PW becoming as popular as WP, and there is no need for it to be so. It is not competing with the mass market appeal of wordpress as it is in a completely different market sector. Huge numbers of users does not equate to a good product, just an overused one. It is not possible to have commercial templates for PW as it has no templating system - how would you know what people call their fields? Do you want to tie people down to only one sort of field name/type/strategy? Do you want to restrict people on how they construct templates? Many of the devs in here do not use a header/footer type system. As soon as you introduce a templating layer (Like Joomla has, for instance) where if you want to do something completely different you have to bung in a ton of overrides, you now have a bulky, slow system again. The advantage of PW is that this is completely missing - this is a good thing. As for standards, everything is built on the API and PHP - that is ALL standards. Any professional can build modules quickly and easily, though for most things like galleries, dancing frogs, and the rest there is no need whatsoever. Why limit people to restrictive module systems when they can just go and grab ANY bit of JavaScript out there and simply drop it in? As I said before, if you want to use PW as a WP clone, then create a profile that has all that sort of functionality - but that is a different product, not PW itself.

The dange is in making PW user-friendly for non-devs it suddenly becomes very unfriendly for developers. A major mistake we all make is comparing ProcessWire to AMS (Article management systems) like Wordpress and Joomla. The point is that ProcessWire, as presented on this site, is not that type of system - it is a content management framework that allows developers to build the CMS or AMS of their own design. Because of the profile system, it would be perfectly possible to build a WordPress clone on top of ProcessWire that would probably be faster and stronger than WordPress - but this would then be a different product "based" on ProcessWire and should have its own related identity, own support structure, own developers and so on. Likewise, I think Apesia's shop module could be expanded hugely into a full profile that again would warrant it's own site, support and so on. But these would not be the core framework that is ProcessWire and should be separate systems and not replace PW.

Such discussions are very difficult for non native speakers but i try my best to harm nobody. since Norbert and Argos were members of my former community, too i have some thoughts on this topics and maybe the reasons of such wishes... We all came from a former real big community with worldwide devs and contributors. The former CMS we used was one of the real big ones that was in use, but in lack of marketing and a scary name "WebsiteBaker" it was not so big public visible.....kinda like PW too. This websitebaker was a great cms (now development is stagnate for the last years) with a easy mediaadministration, simple templatesystem (php), pagetree, one site could have a different template and unlimited sectionblocks where a sectionblock was a addon like a form, gallery, wysiwyg, poll and so on. Cons are that every addon produce own HTML output, not easy to setup, update for a dev. -> But easy to get a website up and running fast.....with strong borders and limits. -> Former CMS was like a setup a db -> install -> install a template ->install some addons ->fast result! But Processwire is a different thing and i've to strict confirm the "hero" and "distinguished" members on theire points! Just some background on my person the short story: - i'm a web-hobbyist, - i studied agrobusiness, - my family have a little farm in southgermany, - i work in a ngo, since a couple of years i've a small business helping people - especially from the agrobusiness to get a more "pro" website up and running than a "standard hoster websitebuilder" could even with a small budget and the very most important thing easy to use/update so they get along. My understanding for OpenSource was always that if you use such piece of code you have two options 1. contribute with your time 2. spend money to push such good work! Since my projects all have a small budget (with some less exceptions) i always try to invest some spare time to contribute, help in forum, try to code something....(In former CMS i was a forummod, wrote several tutorials, assisted several addondevs with translations and testing, started a project for a portable version with preinstalled version on a WAMP server2go) I've not a webdevbusiness to make a living - but since i'm a economist i understand one simple goal/rule: What is good for the client is usually good for me if i running a service with one big exception -> if the good thing is that the client don't need my work anymore! So we talk about "make it userfriendly" or "make it devfriendly" ? i think processwire is a great tool for both devs and users, since i could make the website (and the backend) for my clients real userfriendly without limitation like other cms have. So it is "friendly to me" and after all my work it is "friendly to the enduser"... I don't think that standarisation would be good here - i like particularly that a pro user could adapt a MFC template system and a nonpro like me use a simpler technique. Yes PW more a CMF than a CMS but this is great for everybody that creates professional websites or even apps. @Argos: i think there is a big misunderstanding about the "user" - i think you mean with user -> somebody that use/install/build a site with PW? but i think others here might think user -> client that use/work with a fine adjusted ready to work installation of PW? No offend to you (i honor your work that i know from the last couple of years) and like i said it is hard in a non native language but i try to ask: Since i'm a complete self educated person (no design education, no programming edu) i think that in current times of webdesign nobody without some skills in coding or a partner that devellops for him could stand in the long-range. We live in times of using explicit combination of javascript (if not required for a website - but surely for a app or mobile website), serverside javascript via node.js is on the way, the morst good CMS all works with PHP or even a own language like typo3, preprocessors for CSS like SASS and LESS, JSON data for serving different things, imagehandling for responsive design and so on... since we work with computers and software - all is code - i thought even drawing is just math? @Norbert: there could be indeed more examples, easyer entries for new users -> that wanna try out PW and install it. But hey that is something to do - nothing to write about it. I know you are a experienced programmer so you've no problems to setup a website for a customer "userfriendly" so why this is such a big topic? For my first project i take the time to setup the most things you've mentioned so i can recycle them easy for the next ones... PW is hard for the first beginning - if - you don't search the forum, don't look at the example code in the templates, read a lot of posts, dig through the doc is fun while you learn fast....the tuts in the wiki are old but working. To change this only simple things are to do. Take the 2.5 create template and fields and use the export - share it - so a new user easy get it work with one click and import such examples like a setup for a calendar, news and so on. Or write some tutorials.....if my first project is finished i will do share my learning for other newbees...like other users here did before. @all former other CMS users: PW will/should never be like a other CMS or your former used CMS. Just switch your minds and start to change the way you thinking before - and you will be surprised. I felt in love with pw in lets say about a 30 minutes trial I get the first grasp until lets say the next 3 hours I belief i'll stay for ever in the status Newbee since every day i read this forum i'll learn new things from this great community Best regards - Martin

User-Friendly is very subjective, what's hard for someone is easy for another person. PW requires (and rightly so) that you invest some time in learning the basics (PHP, Jquery, CSS and HTML). These are skills you need anyway to be productive and secure when dealing with a modern day website. Without knowledge of how things work (i.e PHP, Jquery, CSS and HTML), you will never be able to realistically maintain a website. I sincerely hope PW is not "user-friendly" to the cookie-cutter variety out there. They will never take the time to learn the basics, because everything about web development/design is all magic to them. This will most certainly kill this wonderful forum with numerous and countless issues that are entirely based on their refusal to learn simple processes. That would be a shame and will hopefully be resisted. Suggestions on how to improve PW are encouraged and actively discussed on this forum. I enjoy reading the diversity of opinions and concepts. In 2 short years PW has blossomed. I originally had problems understanding why the PW palette was so open, but as time went on and I relearned PHP, Jquery, CSS and HTML I came to respect and appreciate PW. I have read the forum every day for these 2 years. I can say that I never did that with any other software. I hope that we don't inadvertently kill this golden goose on the magical chase for "user friendlyness" and more users. The funny thing is, no matter how "user friendly" PW gets, someone will always think it can be more friendly. That's just human nature at work. To me, PW is already very user friendly and useful. Every client of mine that has seen PW has been happy working with it.

And what else should be in the core? Forum? E-commerce? Local finances tax systems? Should we vote and have in the core the most popular features? Or should we leave the core light and efficient so that even an average developer can quickly create any of those for their clients? Should PW be aimed at the regular Joe that wants a blog like all the others in one day, or should it be aimed at the regular Joe that is willing to pay a competent PRO to create a customised solution? There are dozens of good CMSs made especially for that public, like http://www.couchcms.com/ or http://www.surrealcms.com/ or even http://grabaperch.com/ . These tools don't try to be more than that. They have a focus, they follow it, and they do it well. Pw is actually a very simple system (in the way you mean it), but yes, it is directed at coders and everyone willing to learn a bit of code. But it's not only usable by coders, they are only intermediaries who make it usable by anyone with a business who wants a website. In that context, the potencial users that know HTML/CSS but are not willing to learn a bit of PHP become a much smaller percentage.

What you described here is the opposite of PW. Call it what you want, but if these are your requirements for a tool to call itself a CMS, than PW is not —and won't be— one. This can happen with site profiles though. We only have to wait that they appear, and they will with time.

Committed an little update and upped version to 1.3.3. - added support for PageArray as the third argument. So instead of the root page you give it an PageArray. https://github.com/somatonic/MarkupSimpleNavigation/blob/master/README.md#build-a-menu-using-a-pagearray-instead-of-a-single-root-page So you can do now something like this to build the top level menu entries, where "navigation_entries" would be a page field for selecting pages. $entries = $pages->get("/")->navigation_entries; echo $treeMenu->render(null, null, $entries); Or this would also be possible $menu = $modules->MarkupSimpleNavigation; // get a PageArray from a simple search $entries = $pages->find("template=basic-page"); $options = array("max_levels" => 1); echo $menu->render($options, null, $entries); @sparrow In your case you could now simply do use your "Top_Navigation" as the third argument. $menu = $modules->MarkupSimpleNavigation; $options = array("max_levels" => 1); echo $menu->render($options, null, $pages->get(1)->Top_Navigation);

If anyone is interested in experimenting with this one, grab the latest dev branch. In your selector to $pages->find(), you can specify get_total=count to make it use the count method rather than the calc method. You can also specify get_total=0 to disable any kind of total counting. Though note that it's only counting totals if you have a "limit=n" (where n is any number), so don't bother trying to change the count method if you aren't using limit=n somewhere in your query. Example: // calculate total using count method $t = Debug::timer(); $items = $pages->find("template=basic-page, limit=1, get_total=count"); $total = $items->getTotal(); echo "<p>Found $total items in " . Debug::timer($t) . " seconds using count</p>"; // calculate total using calc method (default) $t = Debug::timer(); $items = $pages->find("template=basic-page, limit=1, get_total=calc"); $total = $items->getTotal(); echo "<p>Found $total items in " . Debug::timer($t) . " seconds using calc</p>"; // bypass any kind of counting $t = Debug::timer(); $items = $pages->find("template=basic-page, limit=1, get_total=0"); $total = $items->getTotal(); // will be 0 or 1 echo "<p>Found $total items in " . Debug::timer($t) . " seconds with total count disabled.</p>"; One thing is for certain: counting totals takes up significant overhead regardless of count method. For large scale usages, having the option to disable total counting with get_total=0 will be valuable for sure. For instance, if you wanted to retrieve the 3 newest news items, but didn't care how many there were total, get_total=0 would be worthwhile. Likewise, if you are using a "Next Page / Prev Page" type of pagination (rather than numbered pagination links) then you also wouldn't need the total count.

I've updated PageFinder to support both the SQL_CALC_FOUND_ROWS and the COUNT(*) method so that I could compare them. I found some interesting results. My conclusion is that COUNT(*) is indeed faster in many instances, but SQL_CALC_FOUND_ROWS is faster in many other instances. Sometimes one is even twice as fast as the other, making me think we might need to build some logic into PageFinder to help it decide which method to use. Though I'm not yet certain why one is counting so much faster than the other at present. Here are the results. Numbers are in seconds. This was testing on a site with ~45k pages. 1. Selector: id>1 (matches 45786 pages) AVERAGE TOTAL (50 finds) ------------------------------------------- CALC: 0.030606 1.5386 COUNT: 0.026732 1.3451 WINNER 2. Selector: template=facility (matches 38008 pages) AVERAGE TOTAL (50 finds) ------------------------------------------- CALC: 0.197568 9.9118 COUNT: 0.183608 9.2142 WINNER 3. Selector: template=facility, title*=senior (matches 1207 pages) AVERAGE TOTAL (50 finds) ------------------------------------------- CALC: 0.053222 2.6943 WINNER COUNT: 0.08826 4.4469 4. Selector: template=facility, capacity>5 (matches 28616 pages) AVERAGE TOTAL (50 finds) ------------------------------------------- CALC: 0.347964 17.4320 COUNT: 0.208856 10.4764 WINNER 5. Selector: template=facility, capacity>5, zip!='' (matches 28145 pages) AVERAGE TOTAL (50 finds) ------------------------------------------- CALC: 0.61547 30.8082 COUNT: 0.407376 20.4028 WINNER 6. Selector: capacity>5, zip!='', limit=2 (matches 28145 pages) AVERAGE TOTAL (50 finds) ------------------------------------------- CALC: 0.435284 21.7988 WINNER COUNT: 0.903338 45.2016 7. Selector: capacity<5, zip!='', limit=2 (matches 4713 pages) AVERAGE TOTAL (50 finds) ------------------------------------------- CALC: 0.097256 4.8961 WINNER COUNT: 0.176476 8.8574 Here is the script I used to test: <pre><?php include("./index.php"); $timers = array(); $selector = "id>1, limit=2"; // change to desired selector $totalTimer = Debug::timer(); $totalRecords = 0; $max = 50; for($n = 1; $n <= $max; $n++) { $timer = Debug::timer(); $items = wire('pages')->find($selector); $totalRecords = $items->getTotal(); $elapsed = Debug::timer($timer); $timers[] = $elapsed; // clear the find() cache so it doesn't get reused on next find() wire('pages')->uncacheAll(); } $total = 0.0; foreach($timers as $elapsed) $total += (float) $elapsed; $average = $total / count($timers); echo "Selector:\t$selector\n"; echo "Average:\t" . $average . " seconds per find()\n"; echo "Total Time:\t" . Debug::timer($totalTimer) . " seconds for $max find()s\n"; echo "Total Pages:\t$totalRecords\n";

I don't think this is something that can be done in a straightforward manner unless you modify and replace InputfieldPage.module, where this label is assigned. However, it seems like a good idea and we can look at making this an option in the core module for the future.