teppo

Under category "revolutionary features": Delete all files and database tables in a single click. Isn't that nice and cozy? .. seriously speaking: haven't heard of this before so can't recommend. In our case Site Profile Exporter makes backups quite simple already, but not that simple, so I guess this could be useful in some cases. Especially if you don't want to / for some reason can't set up server-side automated backups etc. Edit: after taking a slightly closer look at this thing I must say that I'm not exactly pleased, to say the least. They claim it's a free software PHP script, but as far as I can tell only way to see it in action and/or view it's code seems to be by downloading a Windows installer, the size of which is nearly 50MB. Now that's suspicious. Anyway, even if it's not a fake, that's one heck of a horrible way to distribute free software. Horrible enough to keep me away, at least

Just dropping in to say that I'll definitely try this module out soon, looks very promising. Thanks for making this! For the record, I've used mPDF in the past for creating PDF versions of pages. It's HTML and CSS support seemed superior compared to other libraries at the time, at least for my use cases. Might have to switch one site to use this module instead of mPDF just to see how they really compare. Taking a look at your code I'm seeing quite a bit similarities with these libraries; for an example seem to have identical method names. Interesting.

@Samuel: what you're describing here sounds fascinating, at least in theory, though I'm not really sure how it would work in the context of ProcessWire. Which parts of current system would you imagine being useful for this new workflow -- would you still edit content with current admin tools and on page save rebuild site as static version and commit + push it to GitHub or am I completely misunderstanding something here? Isn't that pretty much how Jekyll works, by the way? Anyway, you may want to take a look at this thread, where somewhat similar idea (converting site to static HTML) is already being discussed.

Another option, if what you want to do is simply a static copy of your whole site, is to use something like HTTrack: It's available as a Windows and Linux version + command line tool and (based on my experience so far) most of the time does good job. Windows version can sometimes require a bit of playing around with settings, but other than that it's simple, powerful, very configurable and completely automatic

Just gave it another try and the fix I've mentioned above seems to be working properly. I'm including an in-depth explanation below, just in case you might want to see if there's a flaw in my thought process. I'm also using this module to learn about how fields, fieldtypes and inputfields actually work, so please bear with me.. When a field has already been saved (after initial creation, that is) all inputfield settings have been saved to fields table and thus field knows them too. This is why at this point you can ask "thumbSetting" from field and everything works smoothly. As far as I can tell, inputfield doesn't strictly speaking even have settings of it's own -- it uses settings of the field it's attached to. Or perhaps it's better to say that they share the same settings at this point? Someone please correct me if I'm on the wrong tracks here. Edit: now I'm really getting sidetracked, but if what I'm saying above is true, what would happen if fieldtype and inputfield had a setting with same name? Wouldn't that cause a conflict of some kind, ie. only one of them could save it's settings properly? What am I missing here? A newly created field doesn't yet have any inputfield-specific settings stored, since at the time of creation it won't yet know which inputfield is going to be used and thus cannot guess what it's default settings might be. That's why you'd definitely want to fetch default value directly from inputfield, not the field. Inputfield is the one with default values included at code level after all. This is something I've been unable to reproduce without relying on odd tricks. Essentially this sounds like your field had an image but still it's settings remained empty, which shouldn't really be possible. One way this could happen is if you create an image field, upload image to it and then change field type to CropImage without saving it twice. This seems to leave field settings at database blank and that way cause an exception once you open page edit -- CropImage inputfield tries to render thumbnails for thumbnail list you see below images but doesn't have proper settings and fails with an exception. When this exception happens at image upload phase, it just stops the upload process, but when it happens at this point it stops whole page from being rendered. Interesting stuff Anyway, it would be nice to see what's inside your fields database table for this field (name = "your_field_name"). That might give us a clue why this is happening, or at least if it's caused by what I presume it might be.

Thanks @adrian, fixed

@apeisa, I'm having same problem here that Joss reported. After creating the field it's settings don't initially get saved to fields table (which is probably how it's supposed to work -- I'm not exactly familiar with fields and can't say for sure), thus the need for that workaround Joss mentioned (saving it twice.) In my case it still seems to fix the problem, though, and I've been testing this in both 2.2.15 and 2.2.17. Anyway, I was a bit curious why this workaround is even required. Your inputfield does offer default setting after all, and that shouldn't require any settings being found from the database. After browsing through some code (not nearly well enough, there's plenty of stuff there..) I think I may have found a problem: There's a method called "_getInputFieldInstance", but it actually returns a field. "There's no thumb..." exception is thrown because default settings are always null, which in turn is caused by the fact that you were asking them from field, not inputfield. Following change did seem to fix this situation, at least based on very limited testing: --- a/FieldtypeCropImage.module +++ b/FieldtypeCropImage.module @@ -132,7 +132,7 @@ class FieldtypeCropImage extends FieldtypeImage { // if the image's pagefiles property matches the one with the // field we're looking at, we have a match. save in $field if($image->pagefiles === $pagefiles) { - $field = $imageField; + $field = $imageField->getInputfield($page); break; } } It's getting awfully late and my head is blurry, so I might have to take a better look at this later. Just posting it here in case that I can't remember anything about this tomorrow morning..

That's actually an interesting question. I for one wasn't even aware of PHP ZipArchive's existence and don't really know how well (or badly) it behaves, but it might make sense to use it if it's a) widely supported, b) cross-platform and c) fully functional -- either as a primary solution combined with "if class_exists('ZipArchive')" or a fallback to current method.

Just pushed version 1.0.0 (yay!) to GitHub. No huge improvements involved this time either, just some minor additions, comments, overall consistency checks etc.. and of course support for fantastic new CKEditor inputfield Ryan is working on One notable thing is that now tables created during install actually have proper (?) indexes included. If you've installed this module earlier and want to add these without uninstalling this module first, it's quite simple to do via MySQL client (I'm not familiar enough with PHPMyAdmin to say for sure, but this is probably easy to do there too): CREATE INDEX fields_id ON version_control_for_text_fields (fields_id); CREATE INDEX version_control_for_text_fields_id ON version_control_for_text_fields__data (version_control_for_text_fields_id); Don't worry too much if this seems difficult; these won't make any difference before you've got at least ~50k rows of history data (and even then the difference is minimal.) They should make things a bit faster especially if your site is very large, constantly updated and/or you want to keep history data "forever."

I've seen this happen before, just didn't have the time to see what's causing it then. Now that I did, it seems pretty obvious: JS related to title field only expects keyup, which isn't triggered when you choose a value from autofill list. Making following change would fix this, though I wouldn't necessarily suggest that you make this change locally -- it would make it slightly more difficult to update ProcessWire later. Posting it here just to point out what the problem is/was. --- a/wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.js +++ b/wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.js @@ -25,7 +25,7 @@ $(document).ready(function() { $nameField.val(val).trigger('blur'); } - $titleField.keyup(titleKeyup); + $titleField.bind('keyup change', titleKeyup); $nameField.focus(function() { // if they happen to change the name field on their own, then disable I've also just opened an issue for this at GitHub, let's see what Ryan says

Sounds great, count me in! Do you guys have good ideas regarding how others could participate in this -- pull requests or..? In the past I've been participating in translation projects via services like Launchpad and Twitter Translation Center. This time we don't have anything like that available, though, unless someone wants to set up something similar for ProcessWire. Just saying Anyway, I should probably start by downloading current language pack to a test site and taking a good look at what it covers and what kind of terminology you've used there. We've been using it in our projects with some minor additions and changes, so it might not be a 100% match. Regarding terminology, "sivutyyppi" sounds fine to me, though we've been using "sivupohja". The way I see it, "pohja" makes it more obvious that this is something you can use for new items and therefore fits better what I see as the whole point of a template. Definitely not such a huge difference really and in my opinion both of these are much better options, especially to non-technical folks, than "aihio", "mallipohja", "malline" (or "mallinne" like some seem to type it) etc.

Nico: I'm a bit late to join this party, but.. thanks for making this module! Was looking for exactly something like this from modules directory just last week -- how 'bout adding this there too?

There's not much value to be added to answers above, just wanted to point out that currently URLs (and page names, which URLs are based on) ProcessWire allows follow generic URI syntax as defined by RFC 3986 -- mostly, as you can see from this excerpt from said RFC: Only difference here is that the spec for URL doesn't say anything about tilde "~" having to be at the beginning of an URL, but ProcessWire seems to only allow it that way and thus prevents it from being used in page names. I'm not 100% sure if I'm reading the specification correctly, though.. Anyway, in order to use Asian characters in URLs you'd need to follow IRI specification (RFC 3987) which is simply international version of URI. According to HTML5 specification that's not a problem, since URL is valid if it's either valid URI reference or valid IRI and certain other conditions are met. So, I guess my point here is that currently PW doesn't allow out-of-the-box what was asked in the original post, but who knows -- perhaps at some point it will

I was kind of hoping that this feature would make it possible to add alternate names for homepage too, so that if you gave a Finnish name like "suomeksi" for your homepage, "default version" would stay at "/" and Finnish version of homepage would be reachable at "/suomeksi/". That way one wouldn't need to implement any additional logic to select language at all. I've no idea if that's even possible, though, just thought it might be useful..

Thanks, really appreciate your feedback I know exactly what you're talking about, it's a bit frustrating.. especially since a lot of things I've worked on lately have been a combination of two or even three modules. Anyway, for now adding a notice to ProcessRevisionHistoryForTextFields.module about some settings being in VersionControlForTextFields.module (and vice versa) should help others avoid this problem. I haven't been keeping my modules 100% up to date in the modules directory, should probably start doing that right now. Thanks for pointing this out!

@adrian: thanks for reporting this. That problem was introduced in a recent update, but I'm pretty sure I've fixed it already. Could you check that you're running latest version, 0.9.4?

Antti was probably referring to this thread

@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