teppo

Site looks wonderful and responsiveness fits the design perfectly. Great job!

I agree that it's a bit strange for filesizeStr() to always return value in kB. Haven't used it though, so it didn't bother me before Generally speaking your method seems fine, there are just couple of minor things that caught my eye: Those 's could cause a problem if used outside of HTML context. They're also not being used consistently ("0 Bytes"). It seems a bit strange that it returns "Bytes" instead of "B". All other formats are abbreviations, why not this one? Abbreviation for kilobyte should IMHO be kB, not KB. I've been using a slightly modified version of what you can find here for file-related stuff and that seems to work nicely too.

@Peter: you might want to check discussion about this in another thread (linked by Pete earlier), starting from here: http://processwire.com/talk/topic/992-problem-with-assetsfiles-folder/?p=14452. A bit further down that thread there's a post from Ryan where he explains why file directories behave like they do.

Problem here is that in order to add pages, user needs to be able to edit them too. One way to circumvent this would be a module that hooks to page::editable, checks if user has some predefined role you want to limit edit access for and (if that role is found) only grants edit access if this page was created by current user. There are other ways too, but this is probably the one I'd suggest looking into. A very similar solution is described (in more detail) by Ryan here. Hope this helps a bit.

This is pretty much explained above the config option: "Must be retained if you migrate your site from one server to another". Don't touch it and you should be just fine

@Sevarf2: thanks -- pager problem is now fixed, just pushed version 1.0.2 to GitHub

Validation tools are best used to check for real, structural problems; things that can cause you awful lot of headache when something odd happens in browser X because you forgot to close a tag or some script completely fails to function (or affects more stuff than it should) because your "unique" ID attribute wasn't unique after all. It may have been WordPress that made "code is poetry" a relatively well-known metaphor, but there's still some sense in it; working with pretty and compact (yet expressive!) code and valid, semantic markup is almost like reading a good book. Still the reality is that most people browsing your site couldn't care less whether or not it's "valid (X)HTML", so you really shouldn't sweat it too much either. (Not to mention that if you use editors like TinyMCE and CKEditor, implement any external widgets etc. you're probably going to end up with validation errors anyway.) The point I'm trying to make here is that if it makes you happy then by all means make your markup 100% valid -- otherwise just make sure that there's nothing fatal within those minor errors Regardless of that, adding empty image "alt" attribute is a good habit -- partly because it keeps validator quiet and makes spotting real problems easier but more importantly because it's actually an indicator for screen readers that "this image is not important and should be skipped." If I remember correctly, some screen readers spit out file names whenever alt is left out and that's not very cool or useful. (Will have to do some fact-checking about this later..) On the other hand, using alt texts purely for SEO is an awful idea. Seriously. I'm pretty sure that most people browsing with a screen reader don't appreciate having to listen useless, keyword-infested alt texts unless those also provide some real value for them. Sorry for taking this even more off-topic, but the subject was too fun to skip. @Joss: the site is very nice too!

As far as I'm aware (and since I'm not a lawyer or expert on this subject this may be completely wrong) Finnish law generally considers the fact that user hasn't turned cookies off via browser settings an "OK" for a site to use them. It's still strongly recommended for sites to give visitors information about how and what for cookies are used AND only use them when necessary. Haven't heard of any court decisions about this yet, though.. @extreme84: wire cookie is used to identify each section, in case that something session-specific should be stored. As far as I know, this is also required in order to find out if user has already logged in, which pretty much makes it a necessity. If there's currently an option to stop PW from setting up sessions for guests / non-admin URLs, I'm not aware of it. Minor technical note: session cookies can actually be toggled off via PHP settings, but that's generally not recommended as it would cause PHP to send session ID's as GET params (not sure if POST is also possible, but that wouldn't really change much here) which would in turn result in various security risks, so.. don't do it

Technically speaking calls to /site/ aren't a necessity and that path can even be re-configured to something else by altering $siteDir (/index.php) or default site dir in multi-domain configuration (after moving /wire/index.config.php to /index.config.php.) Admittedly this is quite unlikely.. Another thing to check would be a cookie called "wire", but that can be changed too, so it's not a flawless method either. Overall I don't think there's anything you can use to say for 100% sure if a site is running ProcessWire. On the other hand, the fact that ProcessWire can conceal it's identity pretty well is (in my opinion) a strength; not everyone wants to let general public know which CMS they're using, for various reasons.

Not sure what could be causing this, but judging from that error it would seem that either one of your tables has ascii_general_ci collation. It could also be just one column, which is also possible with MySQL.. or it could be a result of a query forcing a collation, which would seem quite unlikely in PW. Anyway, I'd start by checking if there's anything odd with the query it's trying to do, something related to pages->find() within /fr-fr/rapport_... etc. Could something on your site be sending non-UTF-8 characters to database or..?

Thanks for this, Joss. It's nice to have not only PW but also PHP tutorials here It should probably also be noted that an alternative method for handling CSV strings (which your list there seems to be, though admittedly a very simple one) is to use str_getcsv, which is available since PHP 5.3.0. In the context of your sample code it would look like this: <?php $cars = explode("\n", $page->my_textarea); foreach($cars as $car) { $car = str_getcsv($car); echo "<h3>{$car[0]}</h3>"; echo "<p>Car Model: {$car[1]}</p>"; echo "<p>Car Colour: {$car[2]}</p>"; echo "<hr>"; } There's not much difference between these two methods really, as far as I know even performance-wise they are pretty much equal. Still if there's even a small possibility that you'd need to handle more complex CSV content at some point, using str_getcsv makes sense -- that way you won't need to worry about things like commas inside quotes, escaped characters etc.

True. Should've added that within this context you should actually put a page with same name as said template to first level of your tree to avoid situation you've described above; ie. if you're having home template function as a controller this way, you should actually redirect users to /home/ and make that page your new home page. This, of course, feels a bit hackish since root page ("/") would still be there, though not in use. Wouldn't be the first time this is done, though, so I wouldn't worry about that too much.. and if it's a huge problem, you could always make your root URL behave as index action of index controller with no other actions -- or something like that. Anyway, let's make it clear right here and now that I'm definitely not suggesting anyone should try follow the steps I've mentioned here -- at least not without a very good reason, in which case slight hackishness should be tolerable. Just going with the flow here and throwing ideas around

I'm not very familiar with Laravel, but (if I'm reading your post correctly and you're not talking about something entirely different here..) this sounds similar to how Zend Framework interprets URLs by default: /controller/action/, ie. /index/index/ (or just /index/, in this case latter /index/ is optional) means "use index action of index controller". Typically this would execute indexAction() method of IndexController class. If this is the concept you're talking about, that's easily achievable with PW -- setup a template (such as home) that checks for $input->urlSegment1 and if found, checks if a file matching that is found and runs it. Alternatively you could do all of this within one file, exactly like ZF is doing, so that home.php is a controller in which you specify different actions (functions, if blocks or whatever you prefer) and then run correct one based on urlSegment1 (and if no matching action is found, default to "index".) This could be an effective strategy in certain special situations where you're trying to build more "app-like" structure with PW (or individual app-like part of larger PW site), but as a default it wouldn't really work; routing in PW is based on the idea that each URL segment is a page and not an action like it is in certain other frameworks. This is logical considering the that focus of PW is clearly more in developing web sites than in building web applications, effectively setting it apart from "raw" web application frameworks.

Regarding ProcessWire going for GPLv3, it's also discussed in another thread here. I'm not really sure what you're referring to here; could you please explain which part of the license this is based on? Edit: taking a closer look at the article posted above, I'm guessing this part about upgrading was based on last paragraph there? If that's the case, I don't think v3 actually changes anything. Licensing code under "GPL version x or any later version" is an old convention and other options they've mentioned still require permission from all authors (at least once) and neither of those are specific to v3. Edit 2: mixing GPL with other licenses seems to be rather difficult subject to grasp. I know this is going a bit off-topic, but still wanted to share this article that, in my opinion, helps to clarify how, when and why this can and should be done: http://www.zdnet.com/blog/burnette/gplv3-myth2-you-cant-mix-gpl-software-with-other-software/331.

Certain settings for fields can be changed on a per-template basis; ie. the label of your "title" field for template "person" could be "name" instead of "title". When used properly this helps keep code between templates similar, fields reusable and things in admin interface logical

I'd love to trust Google in this matter, but what I've read so far seems to support the views expressed above: Google is actually making webmasters pay for their "unnatural link profiles", which could theoretically be a result of actions by people they have no way to influence.. although they do also offer a way to contact them regarding this very issue. How common this is and how much (and in what ways) it really affects individual sites seems to be up to debate even (and perhaps especially) within SEO expert community. Taking all things into consideration I wouldn't worry too much about this issue, though it would seem that unless Google decides to alter this behavior "powered by" links are not as good a strategy as they used to be anymore. @OllieMackJames: problem with this proposal is that ProcessWire generally stays out of markup generation and doesn't know what your site looks like or what kind of elements it contains. It doesn't even know if you're creating a website or something entirely different. This module could, of course, work while installed on the default site profile, but as Ryan pointed out above that's probably not a very common situation with live sites and thus doesn't do much good. On the other hand, some kind of slogan / metatag / badge generator would be at least fun but perhaps even useful. I'm thinking something along the lines of HTML5 logo thingy, though enhanced with (random?) slogan generator for couple of different use cases (Personally I'd love to see a WillyC slogan generator. That'd be awesome.)

There's more than one way to achieve this and you can find more comprehensive examples around the forum, but this is roughly the concept I've been using (simplified a lot for this example.) Let's say that you put this in your home template (/site/templates/home.php): <?php // this is your template file, or a controller if you will: $view = new TemplateFile(); $view->some_param = "PW"; $view->filename = $config->paths->templates."views/{$page->template}.php"; echo $view->render(); Then you add a view file corresponding to filename you've defined at controller (in this case /site/templates/views/home.php): <?php // this is your view file: echo "<h1>I'm view for {$page->template} and title is {$page->title}!<h1>"; echo "<h3>{$this->some_param} rocks!</h3>"; echo $page->body; This should be a working example, though not very useful yet. You could expand it by having your view files (or templates themselves) include other files ("partials" or just "include files" depending on terminology, for a global header and footer etc.) or have multiple view files for each template.. and so on. Of course you could also achieve similar results with includes instead of TemplateFile object, though I personally like how this method separates controller from view layer. As always, with ProcessWire imagination is your only limit

Hello there Peter, This may not be of much help, but still wanted to point out that exporting data from ProcessWire for specific needs, ie. where you can easily define what data / which parts of your site / which templates you wish to export is relatively easy to achieve, just not with direct SQL queries: Bootstrapping PW and writing simple command-line script that exports data is one method I've used in the past. Another method, which is especially helpful if you only need to export specific templates, is creating a template file that instead of HTML serves JSON, XML, CSV or whatever format you prefer, accompanied with proper headers of course. If you need to export multiple pages, it should again be easy to write a template file that finds pages you need and renders each of them one after another with render() method of Page object. This is actually something I've just recently used for Excel export on a relatively large client site, accompanied with various user-defined search criteria. Works like a charm. You could also combine these two by writing a command-line script that does exactly what I've described above for exporting multiple pages simultaneously. As a neat little trick you could also switch template file used for rendering by altering the value of $page->template->filename on the fly per page in order to have "export template file" while still avoiding any unnecessary changes or complex logic at the site itself. This is still pretty far from generic export method, but has so far fulfilled all my export needs perfectly fine. PW doesn't force any limits on what you can do with your template files, which is one of the reasons I find it such a wonderful platform for pretty much anything web-related.. and even some non-web-related things

@Luke, just for the sake of clarity: those are all available hooks, which doesn't necessarily mean they'd be "recommended" or "popular".. not sure if that makes such a huge difference though -- I think Ryan once said something about "not removing hooks once they've been in use in order not to break things." Still, some common sense might be useful here

What you're describing here is often referred to as copyleft and it actually requires you to license any modified code under exactly same license as original code, not with a "GPL compatible" license. Important thing to note here is that PW is already licensed under GPL v2, which also contains so called copyleft clause -- there's no difference in this matter between v2 and v3. I'd also suggest that you take a look at this article which describes copyleft principle and explains why it's (mostly) a good thing. It sucks for someone who'd prefer to take a free / open software, modify it slightly and publish it under a closed source license or take parts of it and use those in his/her own closed source application (both of which, in my personal opinion, are rather rude things to do). I do see why some people dislike this, though. To be honest I'm not a huge fan of GPL either, but I do agree that it's a very good way to ensure that free software stays free.. Not true. Neither GPL v2 or v3 forces you to do this. As a matter of fact v3 actually explains this in more detail and is less ambiguous; quoting directly from one of the articles I posted above: This is where Affero license differs from "ordinary" GPLv3 and exactly the reason I said it's too restrictive for my taste

Compared to GPL v2 currently used, how is it more restrictive, could you perhaps elaborate this a bit further? Taking a quick look at some articles and overviews of differences it would seem that v3 isn't such a huge change but could actually make things easier and more precise especially when dealing with other licenses. Affero license on the other hand seems a bit too intrusive for my taste.. I'm no expert in this subject, so I could be completely wrong here. Is anyone familiar enough with these to explain what moving on would mean for a project like ProcessWire?

This has now been implemented (along with a bunch of other tweaks and quite a bit of code rewrite.) Message should be visible on all fields with no stored history rows. If there's exactly one row of data, it'll be visible in revision list, though naturally it'll be only entry there and always selected.

@arjen: I've tried to replicate this in my setup without any success. I'm also running PW 2.3.0 and have been testing this with a template with plain textarea, TinyMCE, CKEditor, alone and in all kinds of combinations, but still can't see any problems. What you're describing there definitely sounds like the bug that was just fixed, but I can't really see why that would still happen, unless you've got an old version of VersionControlForTextFields.js on your site. Could you check that said JS file includes a typeof check for tinyMCE? If that's not the case, this would probably be the cause of this and solution would be to update that JS file too. If it does seem like latest version, I'll need to do more debugging to find another situation where this could happen

Very good point! Multitasking isn't my strong point, shouldn't attempt to answer anything during lectures. It really was the same problem other way around and fix was essentially same as last time too. Sorry folks, this should be fixed in 1.0.3 which is already available from GitHub

Thanks Soma and arjen for that suggestion, I'll implement something like that ASAP.. simplest solutions are often best ones too