teppo

@arjen: current behavior was supposed to be an improvement compared to how it used to work (show one version, which was always active, right after first save) but now I'm starting to think that perhaps it was a mistake. I'll have to think about this a bit more. There are quite a few possible solutions for improving this, I'm just not quite sure (yet) which one would work best here.. About this error, are you already using latest version, 1.0.2? This issue was reported by @apeisa earlier (not in this thread though) and should be fixed now. If it still exists, I'll have to take another look at that one too.

Suggestions are very much welcome and I'd like to hear what Ryan thinks about this too. On the other hand, like @WillyC pointed out above, PW does many - if not all - of the things you've mentioned here very well and still has a lot of potential to grow and evolve. The way I see it, being geared towards slightly more specific needs than other popular frameworks (namely content management) allows PW to focus on what's really important there instead of trying to become everything for everyone. Don't get me wrong, though - I'm not saying that all other frameworks are somehow chaotic. I'm sure they all have their strong points and specialties, my point is that so does PW. Anyway, there have been discussions about integrating other libraries with PW around here and some people still use things like Flourish for certain tasks. I've personally used parts of Zend Framework in the past, but these days I seem to find very few reasons for that anymore, except for certain very specific things. PW is flexible enough to let you work exactly how you prefer and if you prefer to use other tools for some tasks there's nothing stopping you (even if those aren't bundled with PW code.) Last but not least I'd like to point out that unit tests for core code are on their way. Don't worry, we'll get there Edit: Forgot to mention that I'm not (yet) familiar with Composer, though it does sound interesting. Will have to take a closer look. Thanks for the tip!

Hello there and welcome to the forum! Perhaps I'm missing your point, but why not simply use session_id() for this? PW uses PHP sessions under the hood, so this shouldn't be a problem.. of course depending on what you're going to use this information for (You could also grab session ID from $input->cookie->wire, though as far as I'm aware that's essentially the same thing. Note that "wire" is just the default session name set in /site/config.php and if you've changed it to something else you'll have to use that instead.)

You'll need to configure this via field settings; by default time isn't visible at all. Note that there are separate settings for field output format and input field format

For the visual part tags help a lot; each field can have multiple tags and thus it's easy to group fields together in whatever way you want to. They of course "only" make fields list more readable. This "shadow fields" concept Antti mentioned would be interesting to take a step further, though that could become very complicated very fast. Would only difference be name / label or would they actually need to function more like "variation fields", making it possible to inherit most settings from parent field and override them as needed etc.? +1 for the idea about adding limit to repeaters. That would be nice improvement. I know that they're essentially for repeating stuff and for limited use you could always skip repeaters and use individual fields (and fieldsets for visual effect), but sometimes it'd be nice to have the benefits (and flexibility!) of repeaters while still being able to enforce some guidelines for content creators. Repeater with limit set to 1 seems kind of silly to me, though I do see why you'd want that in some situations. I'd still strongly suggest using fieldsets for that.

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

Since this seems to be only place where you're using .on(), you could also check for it's existence first and provide a fallback in order to support both versions: var remove_tr = function() { ... } if ($.isFunction($(this).on)) { $(document).on('click', '.remove_page', remove_tr); } else { $('.remove_page').live('click', remove_tr); } Not properly tested, just posting it here as a rough idea.. Another thing you could do (though it'd still make sense to use .on() if it's available) is replacing .live() with .delegate(), which was added in 1.4.2 and even though it's been effectively deprecated by .on() it still exists in new jQuery versions: $(document).delegate('.remove_page', 'click', function() { ...});

Just tested this in 2.2.9 and everything seems to work here, so I'll have to ask couple of questions to find out what exactly could be wrong: First of all, have you selected fields and templates from module settings? Both are required in order for any data to be gathered. Are there rows in your version_control_for_text_fields database table? (It'd be helpful to know if any data is being stored at all..) Is there anything strange in PW error log (/site/assets/logs/errors.txt) and are you getting any JavaScript errors? It would also be helpful to know a bit more about your environment so that I can try to reproduce this problem myself -- things like what OS is your site running on, have you installed other 3rd party modules and are you using default admin template or something else. If you wish you could also PM me with any extra details.

@formmailer: it's a bit late to say this, but thanks for making this module -- it has been very useful! Also wanted to mention that we've been running this in current dev branch (future 2.3) on couple of sites for quite a while now without any problems, so I'm pretty confident you could already add 2.3 to "compatibility" field at modules page.

Just couple of quick questions: any specific modules you've installed, apart from those included by default -- and which version of PW are you using?

Note: added some clarifications and corrections to my post above, I'm still stuck to some bad habits learned from PHP 4. Posting here to notify anyone who's following this thread (plain edit's don't seem to cause notifications or make the thread show up in list of new content..)

Slightly longer explanation is that it's a problem with scope; you might want to take a closer look at PHP manual entry about variable scope. Essentially you need to use wire() (which is a function) instead of $input (which is an object and thus subject to same scope rules as variables) when you're in the context of a function. You could also pass the function a copy of (or reference to) whatever object or variable you want: function fDtest($input) { if(isset($input->urlSegment1)) echo ":)"; else echo ":("; } echo fDtest($input); .. but that's probably not what you want here. Anyway, hope this helps clear things out a bit Edit: removed reference sign from function call, that way of using references has been deprecated in PHP 5.3.0 and removed from 5.4.0.. and it wasn't even necessary step here, since in PHP 5 objects are by default passed by reference (kind of.) Because of this you need to be very careful when making any changes to objects such as $input inside a function since it'll affect global scope too. To pass an object by value you'd need to use clone instead. Variables, on the other hand, need to be prefixed with reference sign "&" in function definition in order to pass them by reference -- by default they're passed by value.. Thanks to @Nik for pointing these out, my information was outdated!

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