teppo

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

Hello there! First of all, admin panel is by default located at /processwire/, not /wire/ or index.php/wire/. Then again, http://74.52.58.162/~imageeff/?it=/processwire/ opens admin panel as expected, while http://74.52.58.162/~imageeff/processwire/ doesn't, which would suggest that there's also something wrong with rewrites. Did you get any errors while / before installing PW and is your site running on Apache with mod_rewrite enabled? In case that you need help solving this, I'd suggest checking this post (and why not whole thread, for that matter) out first: http://processwire.com/talk/topic/82-install-pw-to-subdir/?p=1253.

Have you already checked this solution out: http://processwire.com/talk/topic/1067-accessing-previous-version-of-page-beforeafter-page-save/#entry9321?

Judging from your error message it would seem that there's already an existing index.php where you're uploading ProcessWire, am I right? If that's the case, you should either clean old files (unless you've already got a working site you wish to use until your PW site is finished, that is) before uploading or create a new folder and upload and install ProcessWire there instead. If you install ProcessWire in a folder and later move it to the root folder of your site, you will need to fix any existing links, though. That's not very difficult and has already been discussed here in detail, but if possible it would be preferable to install PW directly where it's going to be located at in the future.

I personally prefer the aesthetics and UX of Facebook, though I do realize that it's clearly not for everyone. Like Joss already pointed out, they've never been into eye-candy; each and every one of those little details, buttons and links serves a clear and mostly unique function. Another thing I admire is the fact that they've always been happy to make changes they believe will enhance that experience, no matter how risky or how many people they might annoy in the process. Not everything they do succeeds, but at least they have a vision and are not afraid to take the platform further -- something MySpace originally failed to do and one of the reasons it lost it's place as the top dog of social websites. New MySpace does seem like something that could offer real competition though, I guess we'll see how well that works out Regarding Facebook and PHP, they've definitely done a lot to development and reputation of the project by proving that it can be used for pretty big things and also by participating directly via enhancements and bug fixes. Then again, the vast amount of resources they possess have made FB pretty unique and not directly comparable with the rest of us; for an example they're the only company I've heard of that has built and is using their own PHP execution engine

Good point, name field probably isn't best possible solution here. And yes, if that text field would have to be strictly unique it would require a module that makes sure that this is always the case -- or better yet a new field type as Antti pointed out above

There are quite a few ways to accomplish this already: // numeric id should remain same no matter what.. and if it doesn't, no other attribute could be trusted either $pages->get(1919); // like you pointed out yourself, config values are one option; you can set them in config.php or run-time $pages->get($config->teamPagesID); // you could also use your own custom field for this and define it global if you want it to always exist $pages->get('page_id=team'); // if the name of that page is very unlikely to change (and very likely to be unique), you could even find the page based on that $pages->get('name=team'); This is just my opinion, but I'm not confident that this would be beneficial enough to justify a core addition. I'd rather suggest that you turn it into a module; under the hood $pages->get() uses $pages->findOne() which in turn uses $pages->find() and since $pages->find() is hookable you could easily inject your own desired functionality there. This would, of course, require addition of that custom page_id field I mentioned above and perhaps another module / method to fill it in (and make sure that it's really unique) but that doesn't sound too complicated either. Edit: clarification about the uniqueness of name field added, thanks @Soma for pointing this out.

Awesome stuff, Ryan! Interestingly that's something I've always found annoying in jQuery - never understood why traversing only one level would be desirable. I guess it does have it's use cases, but I'm quite happy that you decided to alter their behavior for ProcessWire..

@Joss: like Pete pointed out before, what you're describing there is not only doable but actually very simple to do in terms of module development. In the most basic scenario you'd have a module with only the required methods and most of it's functionality would happen within ___install() and ___uninstall(). This way once the user installs that particular module, it would automatically add required fields, templates and pages via API calls. At least in my experience it's quite common for a client to want new "apps" later on, when site has already been built. In my opinion it would definitely make sense to have a library of "app profiles" (perhaps not the best name, but you'll get the point I hope..) that you could install via simple installer module, possibly even complete with basic "skeleton" template files. Sorry, I know I'm being more than slightly heretic here, but I'm not really promoting the use of modules which create their own markup -- more like modules pointing out that you could use this kind of very basic markup and modify it to your needs. Granted that ProcessWire makes building these kind of things from scratch very easy, still especially for simple, repeatable things these kind of modules could cut boring manual work (making developers happy) and unnecessary costs (making clients happy) and so everyone benefits. Of course this mostly applies to things like news and events etc. which most of the time fit the needs of multiple clients after only superficial modifications (CSS) Regarding original post, I believe that having more ready-to-use profiles is a good thing and something ProcessWire will really need to grow and reach more (especially less technology-oriented) users. One of the things that make our dearest competitor WP so compelling is the fact that you can simply pull out complete template if that's what you're looking for; we should keep in mind that even though PW makes building state-of-the-art hand-made sites very easy, it's not always what a client/user will want and/or would be ready/interested to pay for. Those hand-made piece-of-the-art websites are what I'd prefer to create all the time, but sometimes that's just overkill. Not to mention that sometimes even us developers would prefer to take something basic and just start using it. Anyway, this is just a quick thought and I'd love to elaborate it further, but now I'll have to run to a meeting

@antknight, thanks for your kind words and sorry for taking so long to reply! What you're describing sounds strange, since (unless I'm misunderstanding something) while database contains timestamps in server time, PHP should output them with the timezone you've defined. This happens because class ProcessWire (/wire/core/ProcessWire.php) sets ini variable date.timezone to whatever value is found from config. Just to make sure that everything is configured correctly, if you put following lines somewhere within your site what's the output? if (date_default_timezone_get()) echo 'date_default_timezone_set: ' . date_default_timezone_get() . '<br />'; if (ini_get('date.timezone')) echo 'date.timezone: ' . ini_get('date.timezone');

Thanks, Ryan!

Hello there and welcome to the forum! This sounds mostly trivial. You can do most of that with simple ProcessWire templates - one for categories, another for products and third for articles. Depending on your needs (how you want them to show up and how many of them there will really be) products could be actual templates or just repeater items on category template. I wouldn't suggest using repeaters if you're going to need separate pages for each item or there are going to be a lot of them, but for something like ~10 items on each category where only place their info is shown is that category page they would be an easy solution. Articles could be slightly more complicated, again depending on your needs: you said they should work like a blog, which would suggest that they require comments also. For that purpose there's a built-in comments module though, so that shouldn't be too difficult either. About those admin features you've mentioned, I'd suggest that this content should be added and edited as regular ProcessWire pages. You could always add custom admin panel, but that doesn't really make much sense in most cases. Not to mention that it's a lot of work, the result of which rarely exceeds that what ProcessWire already has to offer