Leaderboard

For those interested, here’s the working proof of concept. https://www.youtube.com/watch?v=x4PedafmKas I have decided to use parent ID instead but I’ll implement template support soon. Should have something ready to release within a few days.

I Googled "alternative to _____" - I can't remember which bloated CMS I put in that line but that's about as useful as Joomla/Wordpress/Drupal has ever been for me. I had been sick of these CMS's for quite some time and PW instantly became a breath of fresh air. PW is great, but this forum is also incredibly inviting and polite which made making my mind up an even easier thing to do. Reading through the explanations and posts of one member helping another made me realize that there was something different (besides being awesome to use) about PW. Thank you Ryan and contributors!

TemplateBy adding the fields you desire to a template you basically model the content/data that you want to manage. Template file Associated to a Template, a template file is where most of the view and controller logic takes place. PW is very flexible so you can also make this more MVC-like, look at this for an example: https://github.com/fixate/pw-mvc-boilerplate/tree/develop Page A page is a data object that always follows the rules and data structure of the associated Template (you could say model). In PW pages are tree based (parent-child relationships). This gives powerfull options of organizing and relating content. Routing PW has a default way of routing following the page tree, but by utilizing urlsegments or hooking into the routing mechanism you can define your own if needed. So PW has it's own way of doing things. It may take some getting used to, but in my opinion it is a very nice way to model and manage your data. I believe one should always choose the right tool for a certain job, so there might be projects that are better suited to build from the ground up using a general purpose framework like Laravel or Symfony. But in my experience PW is the right tool for a whole lot of stuff.

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!

I'm not sure you can directly compare modx and ProcessWire on load times unless you have them both in original state without any modules installed, except those required by the core. Even then, they may not be directly comparable unless they are accomplishing the same thing and providing the same level of tools at bootstrap. ProcessWire's boot time will be very much affected by how many "autoload" modules and running and how much activity they perform during their initialization process. It will also be affected by your overall quantity of modules, fields and templates. I would assume modx to be the same in that regard (assuming they have some equivalent of autoload modules, fields, templates, etc.). So whichever one is faster may have as much to do with how much stuff you are asking it to load as part of the bootstrap process. We do have a rather extensive API that most systems don't, so we do hand over a lot of ready-to-use tools to your template file and part of our bootstrap, and very likely most systems you'd compare PW to don't have near the scope of tools that we do. But we always want PW to have the best performance possible. In PW a "no api calls" page is not going to make any difference in the time of the bootstrap process, because execution of your code (in your template file) occurs after the bootstrap process. Again, I'd assume modx to be somewhat similar in this regard too. I did measure the time it takes for our bootstrap is a fairly blank state (with regard to modules) and found I was getting about 0.2s (200ms) bootstrap times. Admittedly, this is on a slow computer more than half a decade old, but did have APC enabled (APC is an opcode cache). Then I disabled APC and found they were at least 100ms higher. This is the time it takes ProcessWire to boot and give control to your code. As far as how long it takes after that depends entirely on you and what you are doing with the API. I would guess that in Soma's case, he's got a faster computer than me and perhaps with an opcode cache too. Even though my computer is old and doesn't have much in the way of horsepower, I thought there was some potential to speed up the bootstrap process (there is always room for optimization), so I've gone ahead and applied some optimizations to the dev branch, now available in PW 2.4.5. On the same computer as before, I've got the bootstrap down to 0.08s (80ms) with APC enabled, or 0.15 (150ms) with APC disabled (no opcode cache). This is with a logged-in user, so it's a pretty good performance boost. Is it possible to tell the difference in speed in person? No–we're talking about amounts of times that are beyond our perception (beyond my perception at least). But performance is always a priority in our core. And regardless of whether another platform might boot faster than ours or not, I think most would agree that ProcessWire's performance is always better in the areas where it really counts. In PW 2.4.5 (dev) if you want to measure boot-up times, there is now a "Timers" section in the debug info at the bottom, but debug mode must be enabled to see it. Keep in mind that debug mode takes up quite a bit of resources in its own right, so actual times would likely be less with debug mode off.

For those who want to try it, I have uploaded the project on GitHub. https://github.com/plauclair/FieldGenerator I strongly recommend you don’t use it in production for now. It runs correctly without problems, but the module doesn’t have an uninstall method yet. Since it creates system templates and fields, you won’t be able to delete those without going through a big hassle. Currently it also doesn’t have an administration panel, you’ll need to go (in tree) to Admin > Setup > Field generator, and create a new page using the fieldgenerator template. Page title has no effect apart from helping you remember what the rule is.

Here's a video of a module we're working on that I thought you guys might like. The module, Lister, provides a different type of Page List than the tree that you usually interact with in ProcessWire. It gives you a table of pages with customizable columns, filters and actions. Rather than try to explain what it does, I figured I'd show you. This module also uses a new (soon to be released) Inputfield invented by Apeisa, developed by me, and sponsored by Avoine, called InputfieldSelector – it's what you see on the configuration screen as well as the Filters tab. I recommend bumping up the size/quality to 720p so that you can properly see everything. The video has no sound... I tried to do one with narration, but that didn't work out.

Hi Guys, I created a new module to optimize jpegs using the command line tool jpegoptim which yields amazing results, it's comparable to jpegmini.com when using 75 quality. Instructions and usage are available in the readme on github. https://github.com/jdart/JpegOptimImage Let me know what you think! Thanks

After months of silence on the forum I've decided to speak out and introduce a brand new admin theme for ProcessWire 2.4.x I've made the theme initially for our internal business project and I've decided to share it with you all The theme itself is designed only for ProcessWire 2.4.x and up because it's wrapped as a module (new theming design approach introduced in ProcessWire 2.4) and it also has it's own options you can configure. It has all the bells and whistles as Default Admin Theme of PW 2.4 as well as some of my own You can download it from here: https://github.com/nvidoni/AdminThemeModesta and please let me know of any mistakes you find during your workflow... Changelog: v1.0.1 Added unpublished pages status icon next to username (fires modal window with unpublished pages list that you can edit) Improved PageList (children are more indented with arrows before them, hidden pages have more lighter color and icons have more darker color - by suggestion from Martijn Geerts) Other CSS improvements UPDATE: You can find version compatible with Processwire 2.4.4 and up on dev branch: https://github.com/nvidoni/AdminThemeModesta/tree/dev and also let me know about any mistakes that should be fixed. Dev version isn't updated to v1.0.1 yet because of strange problem with theme not switching right (doesn't activate) - it started to happen from 2.4.5 dev version of PW...) and it seems it happens only in Windows environments...), hopefully we'll fix this soon. To sum it up and let the images do the talking, here we go:

I have build another non-profit website http://www.fmgcs.com with ProcessWire 2.4 completely free! This my community website which I redesigned and hookup with ProcessWire. Before it was static html pages. I have spent quit a bit of time on designing and customizing templates. Please provide your feedback as you normally do. Thank you!

Hi everyone! I'd like to introduce PassiveCron - a module, which allows developers to schedule cronjobs - to you. This will be Conclurer's second Pro Module, following ProcessImageMinimize / minimize.pw. PassiveCron is available now as a beta version. What is it going to do? Have you ever been in a situation, in which ProcessWire ran out of PHP's max_execution_time, because you're doing cool tasks like resizing dozens of images using PIM? Or have you noticed site load performance issues when doing a lot of tasks simultaneously? PassiveCron will fix this by giving developers the ability to schedule tasks to future and / or repeating points in time run tasks asynchronously Isn't this exactly the same as LazyCron? No. LazyCron runs your tasks synchronously as your page loads. So running larger tasks will decrease your page's load performance. Instead of this, PassiveCron is able to run those tasks separately from your site loads, thanks to our new web service cron.pw, which will be released together with PassiveCron. How can I use this in my site / module? We will bundle PassiveCron with an easy-to-use API. Let's say you want to call a specific module action tomorrow at 8:00 am: $cron->tomorrow->at('8:00 am')->run('Class', 'Method'); Or do this specific cleanup task, every night at 3:00 am: $cron->every("day")->at("3:00 am")->run("Class", "Method"); Or just run this one large task asynchronously: $cron->run("Class", "Method"); How much will it cost? We are planning to give every ProcessWire site 200 task executions / day for free. For unlimited task executions per site, it'll be around 5€ (pay once, use forever). During the beta period, no payments will be available. Features overview Easy-to-use API for asynchronous task execution Integrable into existing modules for load time improvements No registration at cron.pw needed Pro Cache will be bypassed En- or disable PassiveCron per module Free minimize.pw background tasks Dashboard with reports per task So, what do you think? Is such a module what you need? Can you imagine additional features or do you have wishes for PassiveCron? Please tell us in the comments. Thank you very much!

Hi tehandyb There is a rough translation between traditional terms and ProcessWire's, which is: Templates = tables Fields = columns Pages = rows Template files = controllers & views In ProcessWire, you would create the necessary fields for your content, add the to one or more templates (to define your "schema" in a way), and you create pages based on those templates. The page output is handled by it's template's file. The fields you add to the template can vary from integers to text input to map markers (and more). In your example, you would probably want to create templates for at least event and location. Users, roles and permissions already exist in PW, but you can extend these for your own needs if you have to. The key to linking pages together (individual users, locations and events) is the Page fieldtype. This allows you to create a field that can reference one or more other pages of a type of your choosing. Back to your example, I'm going to presume an event might have one location or none at all. First, create a location template with the basic fields you need. Create a section of your page tree to store them. If you don't want them to show up in lists or searches, set the parent to Hidden. Then, create a new field called location and add it to your event template. Configure it to list pages with a template of location and the parent page where they're stored in your tree. You can also choose what type of inputfield it will use - a Dropdown or PageListSelect might be appropriate depending on how many you have. When you have done that, creating or editing an event will allow you to choose a location from the list. In the event template file, you would access it like this: <p>This is the <?php echo $page->title ?> event.</p> <p>The venue is: <?php echo $page->location->title ?>.</p> I'd recommend reading some more documentation and this brilliant thread on categorising your content.

Pages can hold references to other pages that go beyond the primary tree relationships with the field type "pages". You can think of them as foreign keys.

@Apeisa, just went through my old posts and noticed I never replied back! Sorry, and thank you very much, this worked perfectly!

Thanks for the reminder of this thread. I read it a few days ago. I've written a module, which works, if you save the page. It's on GitHub. There's also a version which extends the FieldtypeCropImage module, but it's css file doesn't get loaded. Isn't "return parent::___render();" calling the __render() function of InputfieldCropImage, where the css should be added? Secondly I would like to enable a ajax "upload" if the user hits enter, while the field is in focus. I'm not that big of a jquery guy and the normal ajax upload is quite confusing with all of the file uploading stuff, while I just need to transfer the url as a string.

new german updates for actual PW dev 2.4.5 (18 June 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--templates-admin--debug-inc.json pw-lang-de-dev-update.zip

The links you generated with <a href="<?=$property->url;?>"> don't go there? Where do they go then? Does the template "properties" have a php file associated with it? That's where you would echo the details using something like echo $page->myDetail;.

Try maybe $pages->of(false) Although I would have guessed in a module usually output formatting isn't on at all, only in templates.

@muzzer: markup cache is definitely a great tool if you've got otherwise highly dynamic pages that can't be cached as a whole. If, on the other hand, the page stays pretty much same on each page load, I'd suggest looking more into template level caching -- that way you'll have entire page cached instead of caching separate regions and then combining those on the fly. If you're really interested in speeding up your sites, ProCache is the ultimate solution. For the most part it'll be serving static pages without involving PHP or MySQL at all, which will always beat the speed of any page built on the fly (regardless of what CMS is used). Just saying.

I don't think you will need to touch the core at all here. The code you mentioned is part of the ___setupNew() function. The underscores prefix mean it's hookable. This means you can create a module with your own function that runs before, after or to replace that one. You can find out about how to do that here: API - Hooks.

Hey Ryan, Thanks for the extensive response. I'll download and try the dev branch and see how that goes, looks like some great improvements. Regarding boot times for processwire; I appreciate that PW is doing a lot of work initially to provide the great API, and I put a lot of the processing time down to this, it's well worthwhile to get the API PW provides. With regards to Modx (Evo) I think modx is definitely more 'basic' than PW but I have to say it also seems blazingly fast. I always wondered if this was simply down to the database style - having all page fields in one page record rather than pulling 30 different field values from 30 different tables when selecting page data. I don't know enough about how you do the database magic in PW to know if this is a point of difference, and my knowledge of SQL is good only to a certain level - modx style. I appreciate we are only talking about milliseconds here, and even 100ms is almost impossible to notice. But from an SEO/pagespeed point of view it is important. I guess the reason I've got a bit pedantic about this is I've converted a modx site to PW and seen it slow down which is not the result I was after! The slowdown was quite extensive until I started using Markup Cache which is so simple to use and so effective. Now with caching the site is loading probably 200ms slower than essentially the same site on Modx, which I'm happy with. Markup Cache: This seems to be a little known and underrated tool. There is not a lot in the documentation or forums about this module. When I get a moment I'll write up a page about markup cache as it seems to me it is not used by many PW users but I've personally found it to be incredibly useful. It's taken some of my heavier pages from sluggish to quick while allowing me to keep dynamic pages dynamic "in part" rather than serving a completely static page using other caching methods. This allows me to collect stats, log views of certains part of a page etc. Keep up the good work bro, you are an inspiration.

@Pierre-Luc Take a look at the CryptoPPP library module which has a couple of generator routines (genKeys() and num2string()) that do almost all of what you'll need for this. Something like... $output = CryptoPPP::num2string(CryptoPPP::genKeys(), $length, $charset); ...where your $length and $charset choices are controlled by your form entries. All you need to do, apart from loading the library module, is check that the $output has not previously been generated if you really want to guarantee that it is unique. (The genKeys() routine is a pretty good pseudo random number generator but, as with all random number generators, its output is not guaranteed unique.)

@Wayne I've fixed those CSS issues (and some other I've spotted along ).

thanks for the hint. new german updates for actual PW dev 2.4.4 (17 June 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). added files: wire--modules--inputfield--inputfieldselector--inputfieldselector-module.json pw-lang-de-dev-update.zip best would be to have a GitHub repo for the dev lang-pack as discussed above, so others can check and correct files if necessary?

Mosravo A couple of requests/pointers before I attempt an answer If your question does not relate to the specific issue in an existing thread, please start your own topic. This way, the conversation remains clear... Not everybody uses the same templating approach in ProcessWire. Not everybody will know what main.inc is, let alone know what sort of code it contains. Please, be as specific as possible in your questions. I am assuming your are talking about the main.inc in the Blog Profile Please, enclose all code within the code tags provided in the post editor when you are making a post (see the icons) Now that we have the niceties out of the way.. First, I would suggest to test your code in a standalone test page using its own template file rather than something as complicated as the Blog Profile. This way, it might be easier to debug.... Second, your image paths look like this: img src='cssSlider/data1/images/img2013122100548.jpg'. That's definitely not a ProcessWire page image path. Using web developer tools, have you confirmed that the images are actually being served? Are they missing? If not, how are you generating those paths? I am assuming you are not hard coding them, or are you? You have at least two choices with respect to serving the images to your slider plugin: You can create either 1 page with multiple images that you can loop through and output the html that is required by your slider plugin or you can have each image be its own page and loop through them outputting the html the plugin needs. You can save your images in your own folders somewhere in your /site/..e.g. /site/assets/myfolders/ and use PW API to get the relative path to your custom folder and serve your images from there I would go for #1. It will help you to read up on the PW image fieldtype API here: http://processwire.com/api/fieldtypes/images/ Also have a look at the $config API here: http://processwire.com/api/variables/config/ Btw, I don't know about cssSlider but its code looks overly complicated? There's a ton of jQuery slider plugins that would produce much cleaner code...just saying

Your website DNS changes haven't propagated to where I'm at yet. Will check it out later today/tomorrow. Looks good. Great work.

There's a permission for viewing a page and a permission for editing a page. Assigning the page edit permission to a role means they see the Pages page in the admin. There are situations where I don't want them to be able to see that (custom intranets). It would be nice if it was possible to have a separate permission to decide whether or not to show that page. There is a way to code around it in the admin template and only show it for roles that I specify, but it would be nice if there was a way to do it with permissions.

here we go == German language for ProccessBlog i'll need this great Addon in some weeks for a own blog, so i will contribute some more lost strings that are not translatable until now....so stay tuned. Thanks to Kongondo! This is really great Addon - i'll love ProcessWire at the first glance it is perfect to setup websites and get learning PHP faster!

While testing I had mostly similar results to those of Soma for the basic site profile out-of-the-box (on localhost), but some actual production sites took a bit longer to load -- around 200-300ms. If we really wanted some comparable results, we'd need all the details of aforementioned tests (including a test site to run those tests on on) just to rule out different measuring methods and side-effects of installed modules

In my test PW needs 0.001s to load config and 0.1s to the point right before rendering a page.

I was surprised to see that 600ms figure so I tested out some pw sites I've worked on. My PW 2.4 sites seem quite a bit slower than the sites using 2.3. I'm using a pretty beefy server and the 2.3 sites have processing times below 300ms where as the 2.4 sites are 600ms+. For the most part that is acceptable but it would be nice if it was faster. Some options to speed up pw: Open an issue on github, make ryan aware of the performance issue Find the bottlenecks in the code yourself, fix them and create a pull request Use ProCache Put Varnish in front of your web server Put Cloudflare in front of your web server Edit: I was a bit hasty, an empty pw 2.4 project executes in around 200ms, those other 400ms+ are my doing.

Hi Neeks, That video is quite old now and much has changed with my system since then, especially the caching technique. Also, caching is not needed as much anymore since I made a lot of optimizations to the code and eliminated a lot of issues that were causing lag. Regardless, PW has a proper caching module called MarkupCache which is the correct way to do the sort of caching I had in the video: http://modules.processwire.com/modules/markup-cache/ My bookmarking system is a good clone of Diigo along with features that suit the way I organize things. (note: Diigo now lets you edit previously bookmarked URLs, which was a major complaint I had about it). Given that this is a true webapp, building it with ProcessWire isn't the best fit, compared to a comprehensive webapp framework like Rails, Laravel, or some of the new NodeJS based frameworks out there (Meteor, MEAN, etc.) although it does get the job done. Being forced into an MVC way of doing things would make sense for a pet-project like this. However, I'm glad I originally built it in PW because it served as a great way to learn about a bunch of features I wouldn't have otherwise been exposed to. I mainly reserve PW for general CMS type sites or sites that wouldn't become true web apps.

Hi again, just as promised: I'm going to give you a glance at two additional features of PassiveCron. 1. Pro Cache Bypass Unlike LazyCron, which is executed parallel to page loads, PassiveCron will be able to execute tasks even while Pro Cache is turned on. So you are able to execute tasks while having great load performance thanks to Pro Cache. 2. No registration needed Unlike ProcessImageMinimize / minimize.pw, there is no need to sign up at our web service. As you install PassiveCron, it will automatically register itself anonymously at cron.pw and just work. In the next weeks we will post more information about PassiveCron and cron.pw as we develop them, so stay tuned.

Hi Jonathan, I might be wrong but I'm thinking that the main reason this is so useful is that with Wordpress there are so many obstacles to overcome and this helps reset them in some way. With ProcessWire basically being a blank canvas I suppose the need is less great? That said, there are sure to be things here that can help speed up any site's development.

Also wanted to add this as a disclaimer for this forum: Any arrangement for work made via this board is a private contract between the individuals concerned. ProcessWire and Ryan Cramer / Ryan Cramer Design, LLC or any of its agents cannot be held responsible for the operation of that contract or any of the financial arrangements and will not get involved in any disputes under any circumstances. If it goes wrong for any reason, it should be sorted away from this community. Thanks to Joss for the suggestion and wording.