Pete

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?

Yep, exactly so I'd have to manually create a new forum for each new module

Just tested on XAMPP for windows - fresh download via the modules manager and worked fine. Can you try again as I've no idea why GitHub would feel the need to redirect you. If that doesn't work, uninstall your copy, delete and try it as a fresh download through the modules manager.

Most forums would have one topic though so what's the point in that? I get that a few have more discussion but it seems like overkill to me.

Remove the single quotes around the 500 maybe? It's expecting an integer and in quotes you're passing it as a string. Oh, then I read the next bit where you did it without quotes and it was no better...

The problem with that is that we will end up with thousands of subforums over time

Hi totoff Is this XAMPP for Windows? If so then you can open that folder, right-click on the file, click on "Properties" and change the permissions to read only in the dialogue box that pops up, then click save. Otherwise you would need to set it to 0644 usually (so that the the program can read from and write to it, but nobody outside the server can). In fact, since it doesn't get changed except manually after that, you could perhaps set it to 0600. As for the chmodDir setting - is that enabled by default? I seem to remember it was commented out by default at one stage, however if it's enabled, you can change it to 0755 and that should be fine I would think. It's also worth noting that this setting for folders only applies to folders that PW creates to store files for file or image fields for pages you create, not the whole system.

No problem, happy to help. Was just passing Manchester shortly after I typed that

3,819 folders reduced to 1,128 - muuuuch better I'm sure some will re-surface as my files section template allows either an external URL or a file as well as an optional screenshot, but I guess they're not updated often past the initial page creation. As you say in the other thread ryan, this could well be run every so often to tidy things up. I guess a nice addition could be to tie it in with the LazyCron module to make that automated on a weekly/monthly basis.

Yeah, good point

I could well make it so that you can set the path as an option and tick a box to check all subfolders, but you would have to click Save before the ASM select lists were updated unless anyone knows of a way to have those fields refresh via AJAX? I guess I could just make the page save automatically somehow once either of the configurable path and checkbox fields lose focus and that would achieve the same, but it should probably at least pop up some sort of confirmation dialogue box so the user has some clue what's happening.

For different sized images the way I think you want to use them, check out the Thumbnails module in the modules directory. It's easy to set up and you can set per-template thumbnail sizes, as well as crop the larger image based off those sizes via the page editor. You're right in your interpretation of how the files are stored for each page in their own folder per page. This isn't a limitation though the more you learn ProcessWire. You can include images from other pages by inserting them through TinyMCE from other pages, and of you really want to you can easily create a page called "Media" for example and subpages for each category and store your images in those in the fashion you would with folders in other CMS' - it's much more flexible this way. For examples, let's say you create a hidden page called 'media,' and subpages called News, Blog and General, all using a template called 'mediagallery'. The template could just have a title and images field. You can then store images under those pages and include them via TinyMCE and you've got that familiar structure already. The beauty though is that you can do other things. Pretend you weren't trying to use it as a file manager but an actual image gallery and in your template for the paret media page you could list all categories by doing something like: foreach ($pages->get('/media/')->children() as $gallery) { echo "<p><a href='{$gallery->url}'>{$gallery->title}</a></p>"; } And then for your gallery page you could list the images using something similar like foreach ($page->images as $image) { and so on. I'm willing to wager though that as soon as you start using ProcessWire that you probably won't want an old-fashioned media manager. How many times are images really re-used across websites? I've built a 500 page site where they haven't been re-used at all, and several smaller sites where the same is true. I'm not saying that a media manager wouldn't be useful to you, just that there is almost always a different, often more useful way of doing things in ProcessWire, so if you could list some examples of where you would need to re-use images we could offer some suggestions. I didn't mean any of that to sound big-headed by the way, just trying to offer helpful suggestions as I know first-hand it can take time to wrap your head around this different way of doing things and un-learn other systems. (Apologies if there are any humorous errors in my post above as I'm typing this all on an iPhone that almost left me typing "wrap your wad" in that last sentence).