teppo

I used to have this printed out on my desk, but eventually just gave up. Every single attempt to implement something properly ended with Microsoft pushing out new (and worse) version of Outlook and us doing tons of extra work "fixing" existing newsletters. The uglier the implementation, better it works and more future-proof it is. It's a screwed up world out there. Anyway, I've also been meaning to properly check out responsive newsletters and see if there's something to that already, but old wounds still haven't quite healed.. and it's pretty hard to believe that things would've improved that much in such a short time

Your PHP code isn't interpreted as PHP, but sent directly to browser. If another PHP file works fine, this does indeed sound strange. Just to make sure, is this a Linux host, is the web server Apache and have you had any issues with .htaccess (or mod_rewrite) before on this server? What about PHP version, could you check that too, just to make sure that it meets the requirements? Also: are you aware of anything else that could be somehow off with this host, i.e. safe mode turned on, suPHP in use or any other "non-typical" detail?

There hasn't been much progress since then (that I'm aware of), but the module is already in production use on some of our sites. It's a lot more stable than the version numbers indicate

Add your new domain name to $config->httpHosts() array in your /site/config.php file. That should do the trick. Just for the record, it would also work if you cleared that array entirely, but it's better to keep list of valid domains there. It's a security feature.

@Pete: thanks for both suggestions. I'll have to see if I can find a way to add these without affecting current behaviour negatively and creating unwanted inconsistencies between API and GUI behaviour This is getting slightly off-topic, but as I've been diving into various version and/or source control systems lately, I've started seeing them, first and foremost, as a way to keep track of what really happened, so that you can later review the full chain of events that led to current state and retrace your steps. That's apparently not how everyone else feels, though. Even Pro Git, which I've been browsing every now and then for ideas as well as Git tips, has an entire chapter titled "Git Tools - Rewriting History", explaining how to alter (prettify, falsify, whatever you call it) local commit history. I guess it's, in the end, all about finding the right balance between flexibility and consistency

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.