Pete

Just store them in a separate something.php file in the templates folder and then in your head.inc file at the top include it like this: <?php include ('./something.php'); ?>

True, true

Mmmmm... donuts.

As for actually checking against and creating an account, you could adapt something like this (note this won't work out of the box, it's just copied and pasted from something on one of my sites): public function checkUser($forumUser) { // forumUser should be an array of: array('uid' => [integer], 'name' => [string]) $u = wire('pages')->get("template=user, user_member_id={$forumUser['uid']}, include=all"); if (!$u->name) { $u = new User(); $u->name = $forumUser['name']; $u->user_name = $forumUser['name']; $u->user_member_id = $forumUser['uid']; $u->addRole("guest"); $u->save(); } return $u; } You could adapt the above to check for a user with a certain name and whatever unique identifier the social networking login methods give you. I'd personally store that identifier in a field in the users template along with a field to store which social network it was - that way you don't run into issues with people from multiple networks having the same username and not being logged in. As usual, there's lots to consider but hopefully that's a start.

We were on that site for a while but the numbers are all rigged on it, or at least can be rigged easily by a malicious script. We actually got to the top, only for a lot of negative votes to mysteriously appear in a short space of time. EDIT: He beat me to it.

There indeed seemed to be an option called RSS Export Includes First Post of Topic so I've switched it on and it should now include the first post

Just for a bit of fun: Before ProcessWire After ProcessWire I was going to be mean and pick on other CMS', but this is fun just on it's own. Post your examples!

Adam quite likes LESS or SASS - I forget which. He only likes them a little bit though, not a lot

There are some good stats in there - I think I can pull new registrations over time in daily/weekly/monthly format, but more useful would be new topics and new posts over time since a lot of registrations might be spam accounts that get automatically blocked. There should certainly be some awesome statistics on Google Analytics for the forums to se how much traffic we're getting - I bet both that graph ad the forum posts/topics graph will be on a nice upward curve

slkworm - that sounds good. Presumably that CSS file would then work fine with my Minify module

I've done this a couple of times recently and changed my dev copy to say "Development" in big letters at the top

Well you're welcome any time

I'm really keen to take a look at LESS at some point since it seems like the easiest to set up (only requires a single .js file nowadays to be called before your CSS files so nothing to do on the server side). I would say that the only time I think I could use it is on a new project or a re-design since some of my projects have huge stylesheets and it would be a pain to change them - plus they work the way they are now My only issue is that using LESS CSS with minify won't work, but I just found this which looks like it could be the best of both worlds: http://wearekiss.com/simpless - basically write in LESS and it compiles back to CSS

PW will only need write access to the /site/assets directory so that should be fine.

Is there some caching taking place somewhere perhaps? Can you go to your site's cache folder (site/assets/cache off the top of my head) and delete the contents and see what happens then.

You'll find debugging tools are generally used far less with web development unless you've used them elsewhere or are really into debugging. Most web developers I know either use a text editor or Dreamweaver - those using IDEs are the exception rather than the rule I would say, and it tends to be people who are used to that way of working with other languages. With PW I don't find there is any "hoping for the best" - it's pretty straightforward if you're used to PHP and have read some of the docs and tutorials. You'll always have a reasonable idea where something has gone wrong in the code and then be able to double-check it against the cheatsheet, so the time saved with an IDE for me doesn't seem that great. I guess outside of the tutorials and the cheatsheet I don't think many people around here have really had the need to run a debugger

Is it not something simple like the fact that you're a logged in superuser? Not sure it'll make a difference but try logging out and checking your output.

After login would make sense to me, and check they're a superuser too if it doesn't already would be my suggestion.

I just drooled on my keyboard. I'll be installing this one on my sites definitely!

Ah yes - forgot about that one. Once those changes are in it will be in the default download You can download interrobang's version from the link he posts to see if that helps in PHP Storm, but I'd still suggest reading up on the other things above too.

It's the easiest function reference, but not the easiest way to get started - I would try the following: Small Project Walkthrough is a good starter The rest of the documentation, specifically selectors because you'll work with them most Scouring the rest of the tutorials forum 2, 3 and the help on the forums is where I got started since the walkthrough tutorial wasn't available at the time. Once I got going and the Cheatsheet was created by Soma it has proven invaluable ever since.

That's not currently possible, but there is a topic all about it here: PHP Storm and other IDEs are mentioned. In the meantime, your handiest reference is here: http://processwire.com/api/cheatsheet/

Well I know I'm only picking holes in your example, but you could do something like this in the template: echo (!$page->color && !$page->parent->color) > 'green' : $page->parent->color; That would of course only check one level up the tree rather than going all the way up until it found a value though.

The only default I have ever implemented was for an article author - it was an ASMSelect field were you could attribute users to an article as authors and I wanted the person creating a new page to be listed as an author automatically. I worked around it in a module with about 3 lines of code anyway, but that's literally the only time I think I needed it. Even then, as I've added articles on behalf of others on that site I found myself removing my name as the default so the default doesn't always apply by any means.

I wonder if there is some way to assume a default value then but not store it? If we assume that a developer with some PW knowledge under their belt would be the sort of person to use this feature then we could offer them some options with the default value: No default value (the default field setting) Default value that is stored in the DB (not desirable in many cases, but it's all about not making assumptions as to what the user will use it for ) A default value that is displayed, but not stored. So if in a very simple example the template outputs the default value using if ($page->field == 1 ? $page->field : "I'm a default value string")... then you don't want to store "I'm a default value string" for every page but it would make sense to have it at least display it as the default value in the page editor. I hope 3 makes sense, as I think that option is the best of both worlds - giving the dev the option to set a default value that's not stored in the DB but is instead handled elsewhere but that it's necessary for other admin users to at least see a default value even if it's not stored in the DB Of course, writing some instructions for this that make perfect sense is another matter entirely