Pete

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

I think some of it might be easier than we think - all it wants to hook into the current list of images for a page for example is a JSON file, so I'm wondering if you could pass it a JSON string instead of the suggested file: http://redactorjs.com/docs/settings/#set_imageGetJson It's the other functionality that would take more time - resizing etc, but it is of course all do-able.

Ah right, probably a setting that needs tweaking by me then.

You can actually change it by editing your profile if you like - click on your name at the top-right of the page, then on My Profile, then click Edit My Profile near the top right of that screen and you can change your Member Title halfway down the page

Nope. Looking at InputfieldTinyMce.js file though it looks like ryan created/adapted some custom TinyMCE plugins to handle that stuff though, so they should be possible to port over: var InputfieldTinyMCEPlugins = ['pwimage', 'pwlink', 'advimagescale'... The drawback is they'll likely need some rewriting to work with Redactor as well as the fact that to work wtih TinyMCE they were written in normal Javascript (which is fine since they're specifically for working with TinyMCE which doesn't use jQuery).

Ah, yes. He has a good point there - it's not as straightforward as it seems.

Is the developer license not compatible? This page seems to suggest so: http://redactorjs.com/download/ Might be worth asking them if we think there's a real benefit (the fact that it's jQuery has me interested more than anything else).

You'll want to bootstrap PW in that file - see this page for instructions to do this and it should work fine: http://processwire.com/api/include/

Is it just that module or others as well that have a GitHub addres?