teppo

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

@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!