Pete

Hi Soma It doesn't work with the new variable width fields - they still sit on separate rows Take your time though - I'm only letting you know as I love this theme and use it on all PW projects

Oh. Oops.

My jaw is somewhere near the floor after that video ryan - that's amazing! Not only due to the fact that you can give names and descriptions (amongst other things) for fields on a per-template basis, but also seeing a very good usage scenario for the resized field widths! I hadn't thought of anything as useful as that yet but can definitely see quite a few templates where that sort of layout is going to work so I'm going to start playing with them right now to vastly improve my templates

I don't think the limitations are necessarily due to Linux then as I had a short-lived experience with a web host that had imposed a 4,000 file limit (files OR folders) in a given folder, so maybe the limits I'm thinking of are imposed by a setting in Apache. Something like that anyway. Or maybe the file system was ext 0.5

ReCaptcha used to be a bit easier to read for humans - now I usually have to get it to refresh a few times before I can read one as it's got a bit silly lately.

Yep - that can often be a worry. The good thing about PW is that whatever hooks your module hooks into will still be here for the foreseeable future, as will the current API. I'll leave it to ryan to confirm, but I don't see the current API calls ever changing to be honest (except in terms of new ones being added) as they're nicely abstracted from the functions themselves, so even if the core code for a $pages->find() call were to change (say something can be refined when PHP6 becomes the norm on webservers in a few years' time) then I still imagine the $pages->find() call in the API will be exactly the same even though the underlying code might get a tweak for performance purposes. Similarly, the hooks that modules use are logically named enough that I can't see them changing either - at least the ones I've used so far. It's this attention to detail - that I'll admit I've only just really thought of in this context - that makes PW considerably more future-proof than other CMS packages. None of this guarantees that modules won't break with new upgrades, but I would say that for most basic module needs that simply use the API to perform certain functions that they would be pretty future-proof.

Christoph - are you sure that the page in question's template has view access for guest users? I can't see why it wouldn't, as the default is for guests to view all new templates, but I'm wondering if this might somehow be the case.

I was just thinking the same thing, but I was thinking of sending data in and out. I think it would be too complicated for PW for various reasons, but would be awesome if it could somehow be configured to work with any page structure.

Wow! That sounds like it would be very useful in a lot of scenarios. I can already see this being useful for something as mundane as "if I have made a new Tweet then add the same message on Facebook". Neat - going to try this out at some point

That sounds great ryan - could you also add a cleanup script to remove empty folders on current sites? I guess this would be something separate since it wouldn't be required for new installs. I suppose the way to do that now I think about it is: Fetch every template via the API, work out which ones have an image or file field, iterate through every page using those templates and remove any folders for pages that have no content in those fields (via a simple $field->count() maybe?).

A super-simple one I employed on one of my forums was a Q&A. The question was really simple, such as "What colour is red" and required users to type the word "red". Simply having an extra field throws off a lot of spam bots especially in more common forms where they're used to a standard number of fields, and when they eventually broke through this first tricky type of question on the forum in question I was able to simply change the question to something equally simple. There was something very satisfying about changing the question just after they'd worked out the last one - I know it's probably all automated but I like to think I've frustrated a human spammer nonetheless

Thanks ryan - for some reason I completely forgot about FieldtypeMulti which will, as you say, eliminate most of the headache as well as be able to provide me with a more sensible single table in the database with many fields, which is perfect for the various scenarios I was thinking of (I actually mocked up an idea for the invoicing repeater before my previous post and noticed I was quickly racking up a lot of separate fields just for that, so this is a much better way to go). Sorry Soma if you had suggested that or that was what you meant - it wasn't until ryan said FieldType multi that it sank in

Just a quick one on custom modules - they were a bit off-putting to me at first, but if you're happy playing with the API then they're not too hard to create. As is often the case, the best thing to do is have a look at some other modules already created - the default install has a helloworld.module in the site/modules but a glance at some of the slightly more complex ones should also give you some pointers. The good thing is that it's pretty easy to hook into most things which leaves the rest of the module down to your programming knowledge (or in my case taking a lead from some of the other modules to see how some things are done ).

I did think serialized arrays at first and they would be cool too, but then you can't easily show multiple invoices for clients with total value outstanding etc - I'm thinking more complex, searchable, sortable needs which is why I thought of repeaters, as then you just iterate through each row and build your totals up to display at the bottom (on the front-end or a client-restricted admin page)

That's pretty much what I was saying - take a look at the example I linked to My thinking was that when they're in the database they're essentially the same thing, so rather than reinvent the wheel... You still want the fields values to be stored separately in the database - for example if you then built a template to display rows from an invoice it would need to calculate the totals for each row (quantity x unit price) and the overall subtotal, tax and total. Similarly you could then build a module to automatically email something like that to a client when the page is published. The way I'm thinking about it, a "row" is a repeatable element, which is where I thought it would be a natural extension of the current module (whether as part of this module or another additional module that requires the current module).

I've been tinkering with this with a view to some sort of invoicing system (if you think about it, the only thing missing to produce something like that in PW was repeatable fields and adjustable-width columns, both of which are now here ). The only thing I feel is missin is the ability to display repeatable fields as a table, or more of a grid view. What I mean is the field titles are repeated with every repeater row, whereas for invoicing or similar needs it would be great to have them as a grid. One of the problems here is that as far as I can tell grid views aren't part of jQueryUI (yet), however when I looked at the example 3rd party plugins I immediately got excited by SlickGrid's examples - check out the Making it editable example, as well as looking at the different ways to display data (although data display should be more about the end-user experience and doesn't belong in the admin, but you get where I'm going with the editable part of it at least). My thinking is that to achieve something like this requires: Settling on a jQuery plugin to use - requires some thought as you wouldn't want to have to change it at a later date ideally Adding a checkbox to repeatable field configuration to choose to display it as a grid instead of the normal repeater - this needs the usual "only tick this if your repeater will display tabular data" disclaimer as it will obviously break if you add image fields or RTE text fields etc to your repeater. Some code to display it as a grid Some code to add a button to the end of the table to add another row, as well as a button at the end of each row to remove only that row I think that's it - sounds easy huh? I'm not sure whether ryan already has plans for something like this, or whether it should be included as part of the current module or as an additional module if it were ever to be built, but I think the possibilities for this could be very exciting indeed.

That'll keep happening a lot throughout your experience I'm sure. I kept looking for more complicated ways to accomplish things in ProcessWire when it turns out that the majority of the time there's a really simple solution. Of course it helps if you know a bit of PHP for the templating side of things, but I'd go so far as to say that the small bit you will need for most projects is easily learned from the default templates.

Yup - I think we were advised to update the .htaccess in one release (can't honestly remember) but it's certainly not the norm and I'm sure Ryan would mention it if it were required.

At the same time though, Linux can have a problem with many files in the same folder, so it's a tricky one to address.

I think that even for slightly more complex pages it could be useful to throw up a modal window that goes through the process of adding that page as you would normally. I've got a few fields on one project where it's more than just a title, so whilst I would like to see a simple option for fields that are just linking to a page with a title I think that being able to add a more complex page would be hugely beneficial. What I wouldn't want to do is have the ability for someone to add a new page title and then forget to fill out the rest of the page after saving the current page, but I think that displaying a large page inline like with the repeater fields could get messy - especially since you need to take into account that page's tabs too. That's the only reason I was thinking of a modal window for it

I'm with Antti - not had a chance to keep up lately with so much other stuff going on and it's been amazing to see all the new things that are coming out lately - good work! I will have a large(ish) PW site up and running by the time you're back and will definitely be playing with this e-commerce module for the next project

I don't suppose you'd be able to share the code would you Bill? No problem if not as I could probably work it out myself next time I need it, but no point everyone doing the same thing either

Thanks guys - Antti's was closest since this field allows multiple values. The goal for this was to pre-populate the author field with the current user's ID if the author field is empty (something that would only be the case on new articles). The check for empty ensures that editing old articles doesn't end up appending my name to them all In the module's init() function we have this: $this->addHookBefore('InputfieldPageAutocomplete::render', $this, 'addUserOnEmptyAuthor'); and the function is simply this: public function addUserOnEmptyAuthor(HookEvent $event) { $autocomfield = $event->object; if ($autocomfield->attr('name') == 'authors' && !$autocomfield->attr('value') && !in_array(wire('user')->id, $autocomfield->attr('value'))) { $autocomfield->attr('value', wire('user')->id); } } So it first checks the field is called "authors", then checks it's empty before adding the current user ID. I also left in another check (that's not required, since the check for empty is enough), but might be useful for others thinking of doing something similar, which simply checks if the current user's ID is in the list of values already. I know that even if it did appear twice in the editor, PW only saves it once, but it would look a bit odd to have the same person's name twice so there's a check for that if anyone needs it. And now I also know a bit more about OOPHP too as well as how to set default values for other fields Thanks all!

Thanks for that ryan - I can see that I can access the array in a function from that - I added a hook that ran a function called 'test' just to drill down to the values: public function test(HookEvent $event) { echo "<pre>"; print_r($event->data['object']->attributes['value']); echo "</pre>"; } This works fine and I can see if a field has a default value, but unfortunately I don't seem to be able to add a value - could you point me in the right direction for that please? I'm not very good with OOPHP, so I tried the following to add page 1306 to the value array and it didn't work: array_push($event->data['object']->attributes['value'],1306); Aside from that I can easily see how to check the field name to make sure it's the one I want (useful as the template has 3 autocomplete fields ) so I'm halfway there. EDIT: Ah, hang on, I found setAttribute in the autocomplete module so I'm nearly there. Will post the whole thing up shortly

Nice module - and distributed under the WTFPL too