Leaderboard

I'd just like to debunk this FUD, cause that's what it is. EVO is now a community supported CMS and a new release is actually in the works by maintainers of several now-dead forks. If it was killed, the download wouldn't be available on the MODX website today. But with limited resources there's no way MODX LLC can actively develop and support 2 major CMSs and while I don't want to claim that the Evo to Revo transition was handled properly, saying that a "kill switch" was pulled on Evo is simply wrong. Slowed down and focused on Revo, yes, killed, no. I don't agree there's difference between an Evo and Revo user profile either. As for MODX 3.0... it will be a continuation of Revolution, but taking a step back and looking at what it is that still attracts people to Evo and what people are asking for, and incorporating that into Revo. Speedier & slimmer core. Content elements instead of resources and TVs. Easier manager customisation. Easier ACLs. There will be no "kill switch" pulled on Revo when 3.0 as we've never done that. It'll be deprecated (as any old version is), but that doesn't mean you're out of luck if you need help with it, and I'm sure there'll still be a couple of maintenance and security releases as needed. The beauty of MODX 3 is that it will be the first time that, following semver rules, actual breaking changes can be introduced since the release of Revo in 2010. And 3.0 will become the priority this year and you'll hear lots more about it after we release 2.2.7. Aaaaaaaaanyway, kinda off-topic here, sorry for that. Yes, you should make friends with ProcessWire because frankly it's a kick-ass CMS with a great community. I'm sure it's very scalable because of the way it is architected (I bet there's a thing or two we could learn from PW for MODX too!) and from what I've seen it's quite extensible too in case you need to move beyond it's core features.

Hi there and welcome to ProcessWire. I wouldn't worry about scalability as it's been tested with at least hundreds of thousands of pages and your first limitation will be with your server to serve content to what I would assume be millions of visitors each month. There's not a great worry about backend performance as features like pagination are actually built into the tree (if you open a parent element with 100 children for example, it will display the first X amount with AJAX pagination for the next page and so on). In terms of database performance, everything is nicely indexed as well. The trick with ProcessWire is that whilst everything is a page on the surface, a page can be anything you want it to be and it certainly adds to the flexibility over some other CMS'. A lot of the questions I had when I moved from MODx to ProcessWire revolved around "can I do X in ProcessWire" as every feature I had built into a previous MODx site seemed to take a lot of effort with some really long snippets and some complicated PHP, but ProcessWire not only let me replicate every feature but allowed me to do it in about a third of the code, if not less. The beauty is that whilst there is some PHP to learn, the API is jQuery-inspired and you shouldn't have to write a single line of SQL as the sensible API calls allow you to do things like this, which whilst requiring some PHP knowledge, leaves you with code that is easy to understand if you have to tweak it months after writing it: <?php /* Let's assume we have a music site - there's a section for artists, under artists we have albums and under albums we have tracks. All are pages (artists would be title, images, body - albums similar and tracks could contain title, length and writer(s) if you like just to give you a rough idea of flexibility - I'll keep the code simple though. */ // Iterate through the artist pages, echo the artist title and body field foreach ($pages->get('/artists/')->children as $artist) { echo "<h2>$artist->title</h2>"; echo $artist->body; // Now list all their album titles and body field foreach ($artist->children as $album) { echo "<h3>$album->title</h3>"; echo $album->body; // Finally list each track on the album echo "<ol>"; foreach ($album->children as $track) { echo "<li>$track->title</li>"; } echo "</ol>"; } } My MODx/PW relationship started out as "let's look at another CMS" and I was quickly converted to be honest. It's easy to understand once you get past the relatively small learning curve and we have folks here who consider themselves beginners but who are coming up with some amazing site profiles and modules. One module which I think might be of interest to you in terms of scalability on the front-end is ProCache. If you have a lot of static pages on the site then that would be invaluable as it caches and serves pages as pure HTML with no PHP or mySQL queries (for member-driven sites it could easily be used to display pages to non-logged-in users rather than touching PHP or mySQL, so anonymous guests get a lightning fast performance and don't add much load to your server). Past that, there are a few other caching options available to you either in the backend or things like MarkupCache (if you have a drop-down list on the site for example that can be updated by adding a page in the admin - a new Album maybe in my above example - then you can use MarkupCache to build that list once, cache it for X hours and only rebuild it after that time. There are other caching options too though so it can be cleared on page save etc). Sorry, my train of thought is meandering a bit this morning, but the short answer is "yes, you should spend some time making friends with ProcessWire" http://processwire.com/talk/topic/2675-processwire-pro-cache-now-available/

Hi there, I need to show the Date/Timepicker in German, so I am using the jQuery UI/Datepicker/Localization like below: $.datepicker.regional['de'] = {clearText: 'löschen', clearStatus: 'aktuelles Datum löschen', closeText: 'schließen', closeStatus: 'ohne Änderungen schließen', prevText: '<zurück', prevStatus: 'letzten Monat zeigen', nextText: 'Vor>', nextStatus: 'nächsten Monat zeigen', currentText: 'heute', currentStatus: '', monthNames: ['Januar','Februar','März','April','Mai','Juni', 'Juli','August','September','Oktober','November','Dezember'], monthNamesShort: ['Jan','Feb','Mär','Apr','Mai','Jun', 'Jul','Aug','Sep','Okt','Nov','Dez'], monthStatus: 'anderen Monat anzeigen', yearStatus: 'anderes Jahr anzeigen', weekHeader: 'Wo', weekStatus: 'Woche des Monats', dayNames: ['Sonntag','Montag','Dienstag','Mittwoch','Donnerstag','Freitag','Samstag'], dayNamesShort: ['So','Mo','Di','Mi','Do','Fr','Sa'], dayNamesMin: ['So','Mo','Di','Mi','Do','Fr','Sa'], dayStatus: 'Setze DD als ersten Wochentag', dateStatus: 'Wähle D, M d', dateFormat: 'dd.mm.yy', firstDay: 1, initStatus: 'Wähle ein Datum', isRTL: false}; $.datepicker.setDefaults($.datepicker.regional['de']); This works fine when it's added into the InputfieldDatetime.js - but just for the date - for the time (which uses the Timepicker addon) one should be able to use this code: $.timepicker.regional['de'] = { timeOnlyTitle: 'Zeit wählen', timeText: 'Zeit', hourText: 'Stunde', minuteText: 'Minute', currentText: 'Jetzt', closeText: 'Schliessen', timeFormat: 'HH:mm', amNames: ['AM', 'A'], pmNames: ['PM', 'P'], }; $.timepicker.setDefaults($.timepicker.regional['de']); ... but I could not get this work when including it into jquery-ui-timepicker-addon.js - so I just changed the options in that file. As it's obviously not recommended to change the code in the modules files, I would like to add the localization by a hook. How could I load a hook always when the datetime module is called? It would work fine with Page::render, but in use with the Form Builder it wouldn't work then, when the forms are embedded by iframe. So it would be great to add the javascript by a hook "into the datetime module"... Would be great if somebody could show me the right direction. Cheers, doolak

I had to give back the nice mention on Joss's song

Okay this was very short notice so it is incredibly rough! But this is for Diogo and all those others wedded to PW http://21stcenturyblues.co.uk/pwdream1.mp3 (Organized, try listening at less than 120db!)

Hey, my very first Processwire module, so please give any feedback possible about the code. Ported from my actual project, maybe its usefull for someone. Main code for tracking based on the clickHeat Project by labsmedia, generated Heatmaps via heatmap.js What it does: Tracking clicks of your visitors Generate a list in admin backend of tracked sites Generate a Visual Heatmap of the tracked clicks. Requirements: processwire 2.3 jQuery 1.9 a folder in /assets/logs/clicks with write permission I don´t have a git repo, I´m sorry. Installation: copy the Folder Heatmap to your site/modules folder. Install the Module: WireDataHeatmap Install the Module: ProcessListHeatmaps Go to your template admin and assign to every template you wish to make trackable the checkbox field track_heatmap Now check this field on every page you wish to be tracked. Known bugs so far: x coordinates about 40px too far in the right. Will fix this issue the next days. Screener and .zip //EDIT 2013/03/16 Roadmap (everybody needs a tiny roadmap ) - change click save from file to database via $page->save() - tidy up the code! -- *almost - segmentation via date range .... learn git? //EDIT 2013/03/17 New Version 0.0.2 Changed saving clicks to files into $page->fieldtype->textarea worked on heatmap calculus... still not working properly, bit too much offset left. trying to fix this problem :-/ update instructions: uninstall old module delete old module files copy folder heatmap to your modules folder and install both new modules. Now add field "track_heatmap" to every template you wish to provide tracking function. Now just check the field on every page you need to be tracked. The module adds his data container to every tracked page after the first registered click. //EDIT 2013/03/18 New Version 0.0.3 little improvement to visualized data. Heatmaps not yet accurate on fluid layouts, some clicks need some browser resizing to match the correct position Updated the attached .zip Heatmap.zip

com.gratlatons To forum for ocre 20.000 massages

I've been wanted to start this theme for a while because ever since I first heard of ProcessWire I felt it needed a really calm theme, one void of clutter and noise. While I may have taken this one to the extreme, I'm hoping some will find it's simplicity refreshing. It will be optimised for mobile devices and you can customise the colours, even the grey. I look forward to posting more of my progress!

I heard about PW by reading a post on the Textpattern forum (which was my previous 'main' CMS). After implementing my first PW site, I never switched back to Txp ;-)

I am frequent nettuts+ reader, so I read this article about PyroCMS and because I was looking for a better CMS solution than all the semi ideal ones out there, it got me interestend. But then I read the comment by Viktor: http://net.tutsplus.com/tutorials/php/whats-pyrocms/#comment-810229080 Never heard about PW before. I came here and instantly had the feeling this might be MY CMS ... so it happened.

const versionMajor = 2; const versionMinor = 3; const versionRevision = 0; @adamkiss: so it would seem

Was just 2.3 pushed to master?

On a slight aside... I am wondering whether TinyMCE should become a /site/ module rather than a wire module - basically so it can be uninstalled, or not installed in the first place. If someone decides to use CK instead (or any other future RTF system), it seems daft to have tinyMCE still sitting in there. (Or has this been already discussed and I missed it .... again.)

Hi, just tested this module in demo mode $config->demo = true; In demo mode is possible delete(move to trash) pages. Nico please make update to deny deleting pages in demo mode. Thanks

Awesome module, really like the idea of heatmaps, a while ago I paid good money to see what happened on my site. Now piwik has a standard overlay feature, showing even percentages for the clicks, and now this again... When are the good things ever going to stop? Thanks Luis for your work, will try on a site after the weekend.

Its over 30000 already. WohOO! More massages!

First impression is nice so far. I'm not sure how, but the Editor displays everything in German (that's good!). The feeling while typing is good. Only thing I'm missing: How can I prohibit the editor from stripping <i> HTML? Searched the config.js but didn't find anything.

pw will never compete with out-of-the-box-blog-engines like wp when it comes to setting up a blog rapidly. from my point of view this is a major advantage of pw.

For sites without a lot of fields, I think that adding a groups designation would just be confusing, at least for new users. So would ideally like to find something that you don't really notice until you are specifically looking for it. How about if the field's 'advanced' tab had a text input where you could enter one or more tags? When used, the fields list would include a list of tags in use at the top, and clicking any one of them would make the list show only fields with the clicked tag.

i.am first you can puut this in your head.inc tamplate or some includeded file before.u are doing $page->url $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; if($page->template == 'article') $e->return = "/blog/$page->name/"; }