teppo

@Soma: I was going to add separate question about whether this will work for homepage too, but kind of thought it'd be obvious that it will. At least in my experience so far that'd seem pretty important, especially if this is going to be used as kind of a "language toggle"

Actually, now that Pete mentioned it (kind of), it might be better to add that hook to saveReady instead of saved. You might have access to password in plain text at that point, but you'd still be (nearly) sure that page will get saved. When hooking to save, there's always the possibility that page won't get saved after all, and in that case it'd be awfully early to send that email I'd still strongly suggest not sending passwords in plain text over unsecure mail protocol. That's why instruction to use "forgot your password?" feature is IMHO better choice.

There's no built-in feature for this as far as I know, but something like this could be turned into a module with relative ease. Since users are essentially pages, your module could hook into saveReady() method of pages and do it's magic (such as sending an email using user credentials, essentially info taken from that page) to this user. Password field is one I'm not very familiar with and thus I can't really say for sure if you'd be able to use it's actual value in this way. You may have to add another hook just to get that. Another option would be to avoid sending passwords and just instruct user to get a new password with "forgot your password" feature -- this is what many sites already do. Anyway, in init() of your new module you'd add a hook: $this->pages->addHook('saveReady', $this, 'sendEmail'); .. and that sendEmail method could look something like this, though probably you'd want to add some checks etc. (does email exists and so on): public function sendEmail(HookEvent $event) { $page = $event->arguments[0]; if ($page->template != "user") return; // stop here if this isn't a new user $message = "your message goes here.. or you could specify it in module settings. Hello {$page->name}!"; mail($page->email, "welcome, {$page->name}!", $body); } You'll find plenty of examples on creating modules around the forum. I hope this helps you get started! Edit: moved hook to "saveReady" instead of "saved."

This one made me wonder whether each page will know it's own URL in each available language or just current language? What I mean is that if you're viewing /about-us/contact/ (via that particular URL) and /about-us/ has Spanish name quienes-somos, in order to switch to Spanish version by using this method you'd want to redirect user to /quienes-somos/contact/. My question is essentially that is there a built-in way to find out that URL while viewing English version of the page? Since you could already achieve this by traversing through parents etc. perhaps a built-in method (as nice as that would be) would also be slightly overkill.. Another thing I'm wondering is that are these names considered equal to original name field regarding overlapping page URLs etc. As an example, if you create a page with default (English) name "/suomeksi/" and then give a Finnish name "suomeksi" to your home page, is your home page going to have an URL ending with "2" or something like that by default? Probably they are and I'm just overcomplicating things, again. Just wanted to make sure.

Resurrecting an old thread to mention that I've been using a Linode VPS for around a month now and couldn't be more happy with them so far. From order to setting things up everything worked properly. Account was ready instantly, web server running couple of PW installations a few hours later -- which is good enough for me. Even latency between my remote Finnish location and their London datacenter seems surprisingly low. Default Linux installation they provided (there were quite a few options to choose from..) didn't include anything extra, which in my opinion is a good thing but also means that you'll have to install everything from Apache to PHP and MySQL etc. yourself. They do provide a very good help for all those steps, though. Anyway, big thanks to Antti for mentioning these guys!

Pete, just a heads-up that I sent you a pull request regarding Multisite support and a pile of other changes I thought were necessary/useful.. Edit: as an afterthought, should probably have sent those as separate pull requests. Not familiar enough with GitHub yet. I hope there's some way to choose which commits you're willing to merge (if any.) Also: didn't read this thread properly before making changes, so I've managed to miss all this 404-related stuff. One of those commits would change hook from Page::render to ProcessPageView::pageNotFound, which shouldn't break anything (except that it changes slightly those cases where sitemap gets rendered, which was exactly my intention) but that might be slightly dangerous still. Works OK on those platforms where I've had the chance to test it, but that may not be good enough yet.

@antknight: they don't matter - in this case. You should take a look at this post by nik where he explains pretty comprehensively how this stuff works

$news = $page->rootParent->find("template=news-item, limit=5, sort=-date"); echo "<ul>"; foreach ($news as $newsitem) { echo "<li><a href='{$newsitem->url}'>{$newsitem->rootParent->title} - {$newsitem->title}</a></li>"; echo "<span>{$newsitem->date}</span>"; } echo "</ul>"; That should be enough. There's no need for "if($page->path === '/')" either, since $page->rootParent always points to parent page closest to root except while viewing root page itself (in which case it points to current page.) Exactly what you need for a task like this

Thanks for the explanation! Like I said it's a new world for me but storing metadata does seem to make sense -- at least for these "serious photographers" you've mentioned

Version 0.9.2 of this module (just pushed to GitHub) introduces support for multi-language fields. See commit details for more info. I've also brought in some minor fixes etc. during this weekend, so if you've installed this module you should consider updating.

@horst: like Soma pointed out above, there are no hookable methods in ImageSizer at the moment. Obvious solution would be to make ImageSizer resize method hookable. So far Ryan has added these in various cases based on proper use cases, so you might want to ask for that Taking things a bit further, I've never really needed image metadata for anything (it just hasn't been relevant to what I've been doing, I'm not a photographer and have never developed a proper gallery of any kind), but if this is something that a lot more people would use and benefit from then it might make sense to consider it as a core addition. Perhaps something similar to what you see in PageImage right after resize call; check a config option and act accordingly? Just thinking out loud. By the way, PHP's exif_read_data() only reads one metadata format, while other libraries attempt to support many others too. This area seems to be kind of fragmented, with many vendors having their own "standards", or am I just misjudging things based on a few minutes of research?

Seems that you've only got 16 MB of memory reserved for PHP. That's awfully small amount and could definitely result in problems like this. Any chance that you could increase this? Similar problem was discussed here and in that case increasing memory limit was the solution. I would suggest something like 128 MB, but according to that thread even 30 MB should be enough

There's a setting for this in Process Users module (Admin > Modules > Users.) It allows you to choose exactly which fields you want to show in users list.

What I've been doing in another module is removing all templates flagged as system. That's probably what you want to do here too. foreach ($this->templates as $t) { // skip system templates if (!($t->flags & Template::flagSystem)) { $f->addOption($t->id, $t->name); } }

I'm happy to hear that you guys find this module useful. I haven't had too much (/any) time to work on this module yet (current status: spitting out essays for school at lightning speed..) but hopefully should get to use most of next weekend adding and fixing things here and there At the moment those arent supported, but that's going to be the very next thing I'll be adding (I hope.) Language-alternate fields are no problem since they're actually separate fields, but multi-language fields use slightly different schema and thus require some extra care here. I actually tested what happens if you enable this module for multi-language field and the result was pretty much as expected: only version that gets saved is the original one (column "data" in field_fieldname table) and if you attempt to roll back an old revision all language versions are replaced with that one. Not exactly useful.. luckily I did kind of expect something like this to come up, so this shouldn't be a huge thing to implement Thanks, Pete! I'll definitely take a look at these ASAP. There were couple of PHP diff libraries I originally browsed through and this may have been one of those, can't really remember anymore. Originally I were a bit worried about including an external library like that with a module. Perhaps that's not such a bad thing after all -- and BSD license should definitely make it possible. Anyway, I'll check this library (and that jQuery merge tool you mentioned) properly as soon as I get some free time Probably the most straightforward way to achieve diff-like capabilities would be building on current method (storing full data etc.) and then either running PHP diff at Process module and getting output via AJAX call or (what I originally planned to do, and still would kind of like to try out) use something like this JavaScript diff algorithm by John Resig.

This module provides simplified (no fancy diff etc. features available, at least yet) version control for text type fields. Originally introduced in another post as a proof of concept, I'm now considering it stable enough to deserve a thread of it's own here. Just so that you know: I've tested this module in multiple ProcessWire installations, three or four different versions in total running on two different platforms, but it still hasn't seen too much real world use. Any information you folks can provide me about how well (or badly) it worked (or didn't work) for you would be considered extremely helpful! So, what does it do? When 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. How does it work? Behind the scenes hooks provided by ProcessWire are utilized to catch page edits. If text fields (such as FieldtypeText, FieldtypeTextarea etc.) selected at module configuration to be tracked were changed, their values (along with some metadata) are saved to two custom database tables. See attached screenshots for better idea about how this thing works. Please note that before you've selected at least one template + field combination to be tracked via module settings nothing will be saved to database! Getting started Module is available at GitHub: https://github.com/teppokoivula/VersionControlForTextFields. Here's a direct download link if that's what you prefer. Installation instructions etc. are available at README.md. If you've got any questions, feel free to post them here or PM me!

You should also see PHP manual page about comments for more comprehensive guide (especially multi-line comments come in handy when commenting out stuff in templates.)

get.pw is already taken, try another name.. was that you, Joss?

Just out of interest, has anyone already registered / considered registering a .pw domain? I only just found out about these.. currently available for copyright holders etc. but available for the general public in a month or so

Your assumption is correct. Images are downloaded during import process.

Interesting topic.. and mvsic.net looks totally cool, by the way! My current coding playlist is a combination of ZZ Top (songs from La Futura mostly), and Maximum The Hormone. Other than that, (a 25 minute dark ambient track by Norwegian black metal artist Burzum) is one of my all-time favorites. This one really helps when trying to get into a flow state.

I don't think that would be possible in any system. You can be sure that compatibility is one of Ryan's main concerns though. First of all, ProcessWire is open source / free software, so there's no one stopping you from doing this yourself. The problem is that if something changes in future PHP versions enough to break compatibility with older versions, there's no way to predict what kind of changes this might require in the system itself and whether they're going to be feasible. What you should keep in mind is that this is very rare and even though at some point new versions of ProcessWire will have to drop explicit support support for old PHP versions (in favor of supporting features brought by newer PHP versions), most likely old ProcessWire versions will continue to work even with latest versions of PHP for a long time.

Minor addition: in cases like this you can limit save to a single field with $page->save('files'). Also, I'm not really sure about this and can't test right now, but if you're doing what Wanze explained above (hooking into pages->save() and running pages->save() there..) you could end up with a loop. By saving only files field at hook function you should be able to avoid that.

Edit: see what Soma suggests below. That's the clean way. I've managed to overcomplicate things, again