teppo

Thanks guys, really appreciate all the kind words! @Pete: you're right, each AJAX upload creates new revision at the moment. This is difficult to circumvent without sacrificing reliability, but I'll give it some thought. Since each asynchronous file upload creates separate POST request updating value of given field, it's actually logical that each of those would also create new revision. From technical point of view this is no different than doing something like "$page->title = 'foo'; $page->save('title');" via API, since the end result is exactly same; whether or not user actually realises it, page content changes instantly each time a file has been uploaded. Anyway, I'll have to see if this could be somehow improved

When we were evaluating CMS solutions a few years ago, the main reason WordPress seemed inviting was the availability of themes and modules, both free and commercial. In a nutshell you can just register to any of those theme sites popping up everywhere and (for a very modest price) get hundreds or thousands of great-looking themes. Grab one, customise it a bit (change the logo and perhaps a few colours) and show it to a client. Congratulations: if the client is happy with that, you've just saved quite a bit of work. That's not what you'll want to do when a client wants really customised look and feel or a set of custom features running behind the scenes for their site (which is exactly where ProcessWire shines) but for those clients that don't care if it's unique and 100% customised to their needs.. well, you get the idea. If the client later decides that he/she needs something more complicated, offer them an upgrade to ProcessWire Custom work, whether it's design or programming, takes time and costs money, period. ProcessWire makes development fun and easy, but won't do it for you. You'll still have to do the work and the client will still have to pay for it. For the record: I'm not saying that one should ever use WordPress (don't get me started on the downsides), but I can definitely see why some folks would prefer it. We've chosen ProcessWire as our main tool and never really looked back. It's working amazingly well for us and our customers.

LazyCron is one option, though you might consider running this with regular cron too. LazyCron is (in some cases) easier to setup, but has to be triggered by user.. and because it's going to be tied to that user's session, it's also prone to problems when used for something slow-running. One simple way to work with regular cron is creating a script that bootstraps ProcessWire, loads your module and executes a method: <?php require "index.php"; // ProcessWire's index.php wire('modules')->yourModuleName->checkSchedule(); After that you'll just have to setup a cron job (usually with crontab, but that depends on your environment) to run this script regularly with PHP (something like "5 0 * * * /usr/bin/php /path/to/script.php", which would run the script every day five minutes after midnight) and you're all set up. .. and if you still want to use LazyCron, you could always hook into LazyCron::everyDay, LazyCron::everyHour etc. depending on your needs. Just be aware that this method may cause issues for you in the long run.

Is memory exhausted on the first call to $scheduled_page->render() or are you handling a large amount of these pages? Depending on the amount of pages you're fetching and rendering, 100 MB getting exhausted doesn't sound too surprising. You could try running wire('pages')->uncacheAll() every once in a while -- it will result in slower execution times, but will also free the memory.

This module is improved and extended successor to Version Control For Text Fields. It handles everything it's predecessor did -- providing basic version control features for page content -- and quite a bit more. Download or clone from GitHub: https://github.com/teppokoivula/VersionControl. This module requires ProcessWire 2.4.1 or later, mostly because of the file features, which require certain Pagefile and Pageimage methods to be hookable. There's no sensible way around this limitation; for those stuck with < 2.4.1, Version Control For Text Fields will remain a viable option. What does it do? While editing pages, fields with old revisions available show up with a new icon in their header bars. By hovering that icon you get a list of available revisions and by clicking any one of those the value of that particular field is reverted to that revision. No changes are made to page until you choose a revision and save the page, which means that you can keep switching between revisions to get an idea what's really changed without inadvertently causing any content to change. The module also adds a History tab to page edit. This tab opens a view to the history of current page in the form of "revisions" -- each of which is a group of changes to page fields processed during one page save (similar to revisions in various source control applications). There are three actions you can perform on these revisions: adding comments, live previewing what the page might've looked in that revision and restoring the page to specific revision. One specific feature that has been a big thing for me personally is support for file (and image) fields, as the original version control module felt rather incomplete without it. I'm hoping to take this a lot further performance, stability and feature wise, but as it stands right now, it's already included here and should be fully functional. Watch the video preview here I prepared a little screencast outlining most of this: http://youtu.be/AkEt3W7meic. Considering that it was my first screencast ever, I'd like to think that it wasn't that bad.. but I might give it another shot at some point, this time planning a bit before hitting "record" Upgrading from Version Control For Text Fields For those already using Version Control For Text Fields, I've added something extra. If you upgrade that module to it's latest version, you should see a new checkbox in it's settings screen saying "Don't drop tables during uninstall". If you check this, uninstall the module and then remove it's files (this is required in order to install Version Control), your old data should be automagically imported to Version Control. Import has only been tested with limited amounts of demo data. Proper tests are yet to come, so please be careful with this feature! Update, 21.6.2015: as of today, this module is no longer in beta. While all the regular warnings still apply (making changes, including installing any new modules, on a production site should always be considered risky) Version Control has gone through pretty extensive testing, and should be as stable as any other module out there.

If you want queries that PW did while inserting or updating those pages, in debug mode use $database::getQueryLog(). That'll return you the full query log, from which you can grab just the parts you need. Another method would be updating database tables manually with custom SQL, but then you'd have to update/insert at least pages (including sort fields), pages_access, pages_parents (in some cases) and each field-specific table individually. You said that "[...] insert and update certain images and [...]". Depending on various factors (amount of images, file sizes, resize settings etc.) updating and/or fetching images could be very expensive operation. Just saying.

It's probably that

For the record, that flickering only seems to happen on Chrome (Mac, don't have a Windows machine at hand to test on). Attached screenshot shows what's happening; for some reason images only become visible at the last possible moment.

I like the general look of this one, except that for some reason this site makes me want to zoom to about 50%.. but that's a matter of opinion, really Some of the images on home page flicker a lot when the page is scrolled. Just saying -- apart from that little glitch everything feels nice and transitions really bring some details to life.

Thanks for sharing this and sorry for your losses. It's always interesting to read about initial reactions to ProcessWire -- it's a great system, but surely there's always room for improvement, and in this regard it's good to have folks with experience from others systems around too. I've never used MODx myself, all I know about it is what I've read from this forum.. and when someone mentions "evolution" or "revolution", I instantly think of Harley engines

@adrianmak: there have been some discussions about non-ASCII (or international) addresses before: https://processwire.com/talk/topic/3000-non-alphabetic-page-name/ https://processwire.com/talk/topic/5270-hebrew-in-url-sergments/ The gist of this is that ProcessWire addresses are URIs, but in order to allow other characters they would need to be IRIs -- the internationalised version. I wouldn't be too surprised if this made it's way into core at some point, it just hasn't been seen as that big a factor so far. Most users are OK with current transliteration method, especially considering that Google might still prefer ASCII over international characters (some sources suggest so, but I'm really not an expert in this field).

That's right. It would be the most straightforward way to achieve that.

I agree with you guys. Actually, last time I checked, current default admin theme had a few quirks with IE8 (one of the reasons we didn't enable it for our clients in the first place), so I don't think we are (or Ryan is) spending much energy towards that anymore. As long as the back-end works properly with IE9, which a lot of our customers are still stuck with, I'm totally happy. When it comes to front-end work, we're using statistics to decide which browsers the sites we build should be most vigorously tested on, and in this regard the situation is pretty good already. According to StatCounter statistics from last 3 months IE8 and IE9, combined, account roughly for 5% of all users around here -- making those a lot less important than IE11, for an example.

Templates without template files are often used to store data. Probably the simplest example is a typical category structure: . |-- home (template=home) |-- blog (template=blog) | |-- blog-post-1 (template=blog-post) | |-- blog-post-2 | |-- blog-post-3 | `-- blog-post-4 `-- categories (template=categories) |-- category-1 (template=category) |-- category-2 |-- category-3 `-- category-4 Those category pages are connected via Page fields to other pages (such as the blog posts in this example), but they're not intended to be visited with their own URLs -- or rendered, so to speak. That's why you don't want them to have template files either. Does this make sense to you?

They sure do, but in many organisations users won't have the luxury of choosing their own tools.. and IT department is most likely to go with whatever is easiest to keep up to date, often meaning whatever was bundled with the OS. Once you've got hundreds (or thousands) of workstations to care for, you're going to need to set some limits, that's just a fact. Not to mention all those custom-built legacy applications that depend on current environment and would cost a lot to upgrade

@Martijn: I'm really not an expert on this, but we've had good results with simple X-UA-Compatible meta tag. Seem to work in most case, i.e. force IE out of the "please break the Internet for me" mode. One gotcha is that it has to be the very first thing on that page (right after <head> opening tag, that is) or it won't have any effect at all. In some cases X-UA-Compatible header is more feasible option and seems to work slightly better even.

Thanks, updated the post

If you're referring to my comments, IE8 isn't important at all -- IE9 still is, as that's what a lot of our customers use at the moment. Can't remember for sure, so perhaps someone else did mention IE8, though..

@owzim, just throwing in some possible reasons: Not all superusers are developers. Whether or not that's a good thing, Hanna Code allows people with no access to actual code to add features that would normally require such an access -- or at least some way to edit files on disk. It's not just about PHP code. Tiny snippets of random HTML or JS can be easily added without having to add files for those too. Hanna Code provides easy way to quickly sketch and test code snippets you're not going to need in the longer term. This is also handy when working in an environment where same site exists on multiple locations sharing database but not code (in which case moving a snippet of code in disk from one location to another would typically require extra steps). That being said, I really believe that Hanna Code would benefit from more fine-grained access management. This could mean three different permissions: hanna-code-html, hanna-code-javascript and hanna-code-php. Or perhaps just two -- hanna-code to add all sorts of snippets and another, limited permission for creating only HTML + JS snippets. The way it is right now, I can't imagine giving a client access to creating their own Hanna Code snippets, but if it allowed me to limit that access to less destructive features this module would have a lot more potential. Edit: almost forgot to mention that of course you could already add the sort of thing you're talking about, though the syntax would be slightly different (filename as a variable). GUI doesn't make that impossible and you don't really have to use it unless you want to