teppo

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

Probably yeah. Seems that I was actually having same problem as Antti. Thanks for noticing this, there's a fixed version at GitHub now

Ryan: thanks for your feedback! As soon as I get some free time for this, I'm going to start making some improvements - judging on your comments and my own thoughts they're going to be mostly about scalability (both in terms of both UI and data.) Main reason for this would be somewhat more manageable (and scalable) data structure. Currently metadata is saved to one table, content to another - which in larger use could result in very large (and thus pretty slow) content table. By using individual files instead of this table might result in better scalability.. though flat file hierarchy probably wouldn't be such a good idea either, since it could result in disk-related bottlenecks in the long run. Another idea would be to just split that content table into smaller chunks. One table for each field, or perhaps each fieldtype? I'll have to take a bit closer look at this one. I'm not even sure if it's really such a huge problem or if I'm just overcomplicating things. What do you think? Probably something similar to what I'm doing with (both) history modules would make sense here too; let the user define this via module settings. Like Joss pointed out, some sites might want to hold on to their data "forever", though I'd like to suggest that abacking things up properly might make more sense in those cases. On the other hand, on many occasions data older than, say, 6 months to a year, wouldn't be of much use to anyone. (Another CMS I've been using stores similar data for approximately 6 months in "easy to get" format, which has been more than enough in 99% of cases.) I guess you're right. It's just that I saw somewhere a nice demo of this and thought it might be really fun to have. Let's see This is a very good point and something I'm going to focus on. Short answer is that it scales "relatively well" at the moment; UI wise this is handled by max-height + overflow-y: auto, but all revisions are loaded and processed when page edit is opened. It could definitely use some extra measures for large amounts of stored revisions, probably something similar to what you've described here. This is very much related to some of the things I mentioned earlier in this post. Removing individual rows might make sense in some cases, but most that's not very high on my list here. I'm definitely going to add a configurable time limit, but would also like a quantity limit (like you're describing here.) If I recall correctly latter was also suggested by Nik and now I've got double the incentive to make it happen

Thanks for reporting this, Antti. I managed to reproduce this by downgrading my test ProcessWire installation from 2.2.13 (though I've upgraded some files independently, so this might not be 100% correct number) to 2.2.9. It was a selector issue at config method. Could you try if updating the module to latest version available at GitHub (0.0.2) fixes the problem for you?

Thanks Ryan! Just pushed those optimizations to GitHub. Regarding development of this module in general, to be honest I don't have a very good plan right now. Other than making minor improvements here and there, I've planned adding some basic features such as proper cleanup of old entries, option for saving actual content to files on disk and possibly a JavaScript-based diff feature etc. Anyway, if you have any ideas what should be included or to what direction this module could move in order to benefit more users, I'd be more than happy to hear your opinions. For an example I wasn't originally planning to support anything other than basic text fields, but support for images/files would definitely be nice addition at some point. Problem is that it would also add quite a bit of complexity to the module (perhaps that should be another module entirely?) and in the worst case enabling a feature like that could end up consuming a lot of disk space without user even realizing it. That's one idea I'd love to take further, but it will clearly require proper planning first..

Fresh install of 2.2.15, everything OK. Only one minor thing seems a bit off, and that's not really related to "technical" aspect of installation: After installing there's this list of important steps to take. Is it just me or does it signal that "this is nothing you should worry about", you know, with light green backgrounds and check marks and all? This was second time ever I've ran the PW installer (usually we do it by duplicating old sites, for various reasons) and I nearly failed to notice that there's still something (rather important) to do.. Apache 2.2.22 PHP 5.3.10-1ubuntu3.5 (Suhosin v0.9.33) MySQL 5.5.29

Originally inspired by a comment by Pete on Process Changelog thread, I've been playing with (and just pushed to GitHub) an experimental version control module for text based fields, which does some of the things discussed here. Somewhat coincidentally it also bears quite a bit of resemblance with the mockup Ryan posted above UI wise.. It's not production ready, only supports storing content to database (though adding another mechanism for storing the bulk of content wouldn't require much work and most likely will get added soon) and currently only supports Text and Textarea fields. I'm looking into this subject more closely once I find some free time for it, but in the meanwhile anyone interested can check it out, use it, fork it etc. as long as you're aware of the fact that it's more of a proof-of-concept than anything else and that it's far from a perfect solution in more than one way. Regarding Drupal 7 diff module posted above by @ceberlin, this module doesn't provide that kind of features at the moment, though it does store all necessary data (and a bit more) to enable those at some later point. I was originally planning to only store diff data, but since PHP doesn't have native method for doing that I ended up storing full content on each edit. Not very efficient, but for small-scale use (or proper limits, to be added later..) it should be good enough (for now.) I've also omitted many other features, such as those mentioned by Ryan above (modals etc.), for the sake of simplicity and feasibility. Anyway, if anyone is interested to try it out I'd be very happy to hear any comments on this one

Looks awesome, thanks @Wanze! This'll come in handy especially for some of our bigger sites, I'm sure @Luis: some things can't be unseen. Going to have difficult time maintaining serious expression while introducing this module to coworkers or clients, simultaneously avoiding this image of dancing badgers..

Hello there, @artaylor, and welcome to the forum! Just like Pete above, I've got absolutely no problem with template engines - as long as they stay out of my way What I do have to disagree with is the general idea that template languages makes things simple and programming languages difficult. Template languages generally start with a good idea ("separate code / logic from markup / view") but eventually end up re-creating much of native functionality and only making things more complicated for everyone. Designers still need to learn new (template) language and developers not previously acquainted with that particular template engine have to do the same just to keep up and provide often necessary support. Just take Twig as an example; it's really quite amazing how complicated structures any moderately resourceful designer can create with relatively simple tools like macros, conditional logic, variables - especially when combined with template inheritance and horizontal reuse. I also strongly disagree with your notion that designers would need to know and understand "a full programming language" simply to create HTML template with some variables. Exactly why would they need to do that, if all they need is echo and some simple control structures? How would this part be so different when using a template language instead of PHP? Based on what you've said there some template languages seem to be pretty fault tolerant, but I can't help wondering if that's really a good thing - I mean, why shouldn't there be an error if something is clearly broken? What if it causes misleading information to be spread out, UI to be broken or any number of other problems? One thing I do see value in is sandboxing, though. Like you pointed out, sometimes it's necessary to set limits for the amount of damage an inexperienced designer (or developer) can unintentionally cause. This is a good argument for template languages, though I'd still argue that most of these issues can be avoided altogether. Pete and others have already provided valid solutions above. Another important thing is to never make changes on live environment. That's just plain wrong and will definitely cause problems eventually, no matter how skilled folks you've got. You can also provide designers with a simple checklist of things to a) do, b) not do and c) be careful about. IMHO that's much better than making everyone learn yet another language. All that said, there's clearly a lot of interest in template engines around here nowadays, so you can be sure that eventually you won't have to teach another row of PHP to a designer. I still honestly wish that more designers could get over their phobia of these evil programming languages and realize that they're not that bad after all. This is one of the reasons why I won't ever advocate disguising or wrapping PHP (or any other "programming language") with something that's ultimately just another layer of complexity Edit: even though this post is already horribly long, I just had to add that the way I see it such things as "pure" programmers, front-end guys or designers rarely exist in the world of modern web development - and that's a good thing. Learning what others do and how they do it, even if it's just the basics, can benefit everyone. No one benefits from tightly set roles, such as "designer can't write PHP, period."

No, but downloading right now. Sounds pretty sweet already, even with that "use at your own risk" disclaimer. Thanks for the tip! For the record, I've been struggling with this same issue for ages. Aptana seemed like the perfect solution, but so far I've tried and discarded it couple of times already. It just doesn't feel comfortable, everything about it is somehow "too heavy." Not exactly surprising, since (as far as I know, though I might be completely wrong too) even the standalone version of Aptana is based on Eclipse.. Anyway, NetBeans might be worth giving a try if you want IDE features without all that fuss. I haven't used it in a while now (these days I prefer to do things server-side with Emacs and I don't really feel any need for local development) but it used to be pretty much only IDE I could stand. I've only used NetBeans with SVN, but it supports Git too.. and SFTP sync, if that's really what you want

Taking a look at similar module for Drupal 7, this doesn't seem too complicated. You'd need new inputfield for the use of textarea fieldtype - or perhaps new fieldtype extending textarea - which would instantiate Etherpad on the fly. That field would have an option for pad ID and you'd have to create author ID on the fly (like that Drupal module is doing).. or alternatively you could only allow editing these fields for users with author ID in their user info. IMHO real world use cases for a field like this would be somewhat limited because of certain security issues. Sounds pretty fun, though, and very much doable.. anyone?

For application-related cookies answer is "it depends on what you're building and for whom." Especially if it's purely UI related, non-critical stuff JavaScript is more than ok, but for anything more serious (where page loads are possibly happening anyway) PHP's setcookie() gets my vote. Then again, if you're working in an environment where JavaScript is required, it doesn't really matter -- whichever is easier to use I've used jQuery cookie plugin once or twice, but the amount of "regular" JavaScript required for simple cookie getter / setter functions is so minimal that it's usually faster to write those functions locally and forget using plugins. @diogo: black pepper, seriously? I'm obviously no cookie master, but that sounds strange -- though I could imagine baking some nice chili cookies myself..

This should get you pretty close: ... if($question->name != 'title'){ $inputfield = $question->getInputfield($page); | $parent_id = $inputfield->parent_id; ...

This module tracks changes, additions, removals etc. of public (as in "not under admin") pages of your site. Like it's name says, it doesn't attempt to be a version control system or anything like that - just a log of what's happened. At the moment it's still a work in progress and will most likely be a victim of many ruthless this-won't-work-let's-try-that-instead cycles, but I believe I've nailed basic functionality well enough to post it here.. so, once again, I'll be happy to hear any comments you folks can provide https://modules.processwire.com/modules/process-changelog/ https://github.com/teppokoivula/ProcessChangelog How does it work? Exactly like it's (sort of) predecessor, Process Changelog actually consists of two modules: Process Changelog and Process Changelog Hooks. Hooks module exists only to serve main module by hooking into various functions within Pages class, collecting data of performed operations, refining it and keeping up a log of events in it's own custom database table (process_changelog.) Visible part is managed by Process Changelog, which provides users a (relatively) pretty view of the contents of said log table. How do you use it? When installed this module adds new page called Changelog under Admin > Setup which provides you with a table view of collected data and basic filtering tools See attached screenshots to get a general idea about what that page should look like after a while. For detailed installation instructions etc. see README.md.

Just to make sure: are you actually trying to run code under the hood or perhaps just refresh the browser window at specified interval? If your intention is just to reload / refresh the browser window, you'd probably want to use JavaScript or meta refresh tag for that. Cron (whether lazy or regular) is intended to run code under the hood at regular interval, but it won't directly affect browsers / clients viewing the content. If your application needs to fetch content from somewhere (such as Google Calendar), you could use a combination of lazy cron and JavaScript to achieve this, though lazy cron part would be somewhat irrelevant as long as this is just a proof of concept. For the time being you could also have your page check for new content on each page load. If you're interested in taking this concept a step further, you could also take a look at something like https://github.com/viljamis/Remote-Preview/ as a reference project. It has certain similar features to what you're building here (unless I'm completely mistaken) - primarily that it updates client machines browser window on an interval. The thing that makes Remote Preview feel more sophisticated is that refresh is only toggled if an AJAX query to a text file containing an URL confirms that it has changed since previous reload. Difference between that approach and a plain meta tag / JavaScript refresh isn't huge, but it definitely makes it seem more elegant

Regarding that (and actually this whole topic in general, to some extent) you should take a look at Process Tools Create Pages module by Soma. That's exactly what it does

Honeypot as described by @yellowled, sometimes (depending on what you're building and for whom) accompanied with some JavaScript magic to make it sligthtly more efficient, still seems to work surprisingly well. I haven't felt any real need to apply CAPTCHA's in years. Just saying Anyway, this 2011 smashing mag article illustrates in great detail most common spam prevention solutions. It also points out their strong and weak points and even mentions some methods I hadn't even heard of before, like the slider -- that's actually damn elegant, but of course limits your audience, as they mention in the text.

Sorry for taking this even more off-topic, but my vote goes to APL.

In my humble opinion what's most notable about short echo tag is that it's inconsistent with everything else in PHP. Since this is another age-old "my programming style is better than yours" discussion, I'm trying not to go too deep here, just saying that I'd very much prefer one clean syntax over multiple variations. And yes, I know short echo tag is just one little quirk in the whole PHP soup, but still The RFC for short tags introduced two basic code samples: This is a home page for <i><?php echo $user; ?></i>. Last visited at <?php echo $lastvisit; ?>. .. and .. This is a home page for <i><?= $user ?></i>. Last visited at <?= $lastvisit ?>. .. summed up with rather one-sided "The second form looks much nicer and cleaner". Personally, I have to disagree with that: First example makes it clear what's happening, even if you're not familiar with PHP - as long as you're even remotely familiar with pretty much any other programming / scripting language; you're using PHP to echo (output) a variable. Plain and simple. One could insist that "print" would be even more universal, though, but in PHP it suffers from minor performance overhead so I'll let this one slide. Second one does exactly the same thing, but with obscure syntax (again in my opinion) that's unique to even PHP itself. Don't get me wrong - I do love PHP. It's just that I also love everything that's consistent and would prefer if devs took it that way instead of nurturing so many different syntax choices, naming conventions etc.

+1 for integrating into main comments module as an option. Personally I prefer flat comments (as strange as it may sound, I find these easier to follow, since they're always in the order they've been posted) but I can think of many cases where nested comments would be preferred. Great job @Khan!

Hello there - and no worries, all questions are welcome In terms of logic and doing it "ProcessWire way" I think you've pretty much nailed it. Page fields are exactly what you'd want to use for these kinds of situations. Regarding your code sample there are two things I'd like to point out: PageArray acts just like regular PHP array in many ways, so you don't have to convert it to array with explode etc. before count or foreach. When you're looping through PageArray, you can access each pages content directly, so that way there's no need for new $pages->get() call each time This is probably how I'd rewrite that code of yours: if ($page->related->count()) { echo '<h2>'.$page->related->getTotal().' Related Entries</h2>'; echo '<ul>'; foreach ($page->related as $related_page) { echo '<li><a href="'.$related_page->httpUrl.'">'.$related_page->title.'</a></li>'; } echo '</ul>'; } Hope this helps!

Adam, you should take a look at /wire/core/Pages.php, after that it's pretty obvious where to attach page-related hooks. And for the record, ___restore() and ___restored() are available too if you happen to need them