Pete

It's reduced Martijn to incomprehensible sentences!

I think a better search module in the admin (no offence ryan, it does work as it is of course!) or at least an alternative could be implemented whereby you can select fields/templates/pages and do some really advanced things without getting overly techy with selectors. As a real-world business example, creating rules in certain versions of Outlook takes you through steps - not that this needs steps - of selecting your first criteria, then a second and so on. It would be neat to be able to chain criteria in a drop-down interface where you can have as many criteria as you like with one per row. For example with drop-downs and some AJAX (for subsequent drop-downs at that stage) you could achieve: 1) Template equals "blog-page" 2) and body contains "pasta" What I mean by this is that for users who aren't the web developer there could be an easier way to present searches in a way that reads exactly how it appears on screen. The two separate lines are for two criteria, but equally you could add 6 for a big site to drill down into some complex stuff. Just thinking that something human-readable (devs are super-human of course) will be better for the less techy content editor whilst devs should be aware of the selectors by the time they've built the site

It was the name that had me stumped - couldn't remember what it was called but, as ever, it's a fitting title!

I think Soma's new module that loads page editing in modal windows and keeps the page tree always in the background (you may not have seen it yet ryan as it's that brand new and I've lost the link already) covers a large part of this and I can see it fitting certain workflows and personal preferences nicely. I'm sure Soma will oblige by linking us to it

...but it can be painful to go back to after using various other tools But on a more serious note, ryan is right of course.

Soma - off the top of my head you wouldn't want to do it with JS as you might only want particular drop downs to be non-click on the parent (confusing for the end-user I know, but I've seen it before!). I know it's not exactly best practise to mix and match what can and can't be clicked at the top-level of drop-downs, but people will want to be able to do it nontheless I guess one way to achieve this would be to add another field by default that's a simple tick-box that says something like "Simple Navigation Placeholder" or something that can appear on every page template by default, maybe in the Settings tab? That way it's a simple check for a tick in that box per-page when looping through the output. If not, and we assume that there is just a module setting to make all top-level drop-downs be non-click then that could just be a simple check for that setting in the module config and loop through. I've just realised what you mean with the JS as I'm typing this (d'oh) but I was still envisaging that behind the scenes Google could still see a URL to the top-level even if you're telling the browser for the end-user not to be able to click a top-level menu item, so I just wanted to suggest a few options you've likely already considered

I well as far as I'm aware it shouldn't matter unless the form is doing something ridiculous, but it's partially up to the end user to have a look at any third party code they download if you're unsure. As with anything on the internet it's downloaded at your own risk. What I would say is that SQL injection attacks shouldn't exist in the usual way in ProcessWire because the modules never run queries directly - they use selectors and other functions available to the front-end templates too. As such it all runs through sanitisation routines in the core so that out of the box this is a much more secure system than many others, and modules have an extra level of security as a result of not running queries directly. That's not to say someone couldn't code something badly of course which was the purpose of my first paragraph in this post None of this means module authors should forget about validation, but what passes through the core functions is sanitised to at least prevent SQL injection (I'm sure Ryan will be able to step in and go into it in much more detail).

I had thought of a similar scenario where this would be useful yesterday but can't remember it now. In other topics we've said to not bother with this as you can get all the correct info to show on the front-end by just adding a person to a team in one place and using selectors, but I think my scenario where this falls down was if one person is in charge of adding teams and only has those permissions and someone else is im charge of adding/editing team members and you want both to be able to see each others content im the relevant pages. The easiest way would be with a module that's coded so that an update in one field updates another field - relatively easy I think - but what I think would be even better is a module that extends the Page fieldtype so that you can specify other fields that the current field updates in the field config so it doesn't have to be hard-coded in a separate module. What do others think, assuming I made sense?

Paypal is reasonably straightforward to implement from scratch from what I remember dabbling with the basics some years ago - their docs were pretty good at the time.

This would assume they can get into the database in the first place in which case it's probably game over anyway... Not sure how I feel about this as it would be better to educate people about various attack methods than obfuscate table names for some sense of security that I'm not convinced it provides.

You went away for five minutes and it's like we all went hyper. Welcome back!

Love it! It's a different way of always having easy access to the tree and not losing your place. The way I was thinking of last week was having the page tree in a sidebar area a bit like MODx but this works better with any size of website. Now slow down, you're making the rest of us look bad

Depending on whether your products have variations like size and colour (clothing and such) or not that would determine for me whether to use PW and FoxyCart or something specific to e-commerce. The problem is that you could end up with 5 colours multiplied by 7 sizes and have different weights, costs and inventory for each, and there are more complicated examples than that - that's something that you might want to turn to specific software. If on the other hand you're dealing with simpler products like books or other products that don't have variations (or certainly don't have many) then PW and something like FoxyCart would be perfect.

Not a bad idea. I am aware that there are already a lot of forums and maybe better ways of organising them so I've got a doodle I want ot run by ryan before adding too many more. When I said coding examples for download, I just meant if someone wants to use the starting HTML-only template and integrate it rather than starting from scratch and typing every example in the book. Just thought it might be easier than having to type the HTML as well.

I think the Cheatsheet should also be in the book. Not sure quite how to lay it out but I have seen other examples in other coding books so I'll have a look as there will be something sensible. Maybe we can have a pull-out poster (someone suggested a tea towel the other week which isn't a bad idea ). A book can also be used well with downloadable examples - you could quite easily tell people to download the software, grab some example files that have the bare bones of a HTML template and get them to integrate a basic HTML template (separate from ProcessWire) into ProcessWire. Maybe the best example is to have a basic 5 page website currently built in HTML that has a basic contact form (doesn't need to work) and a basic gallery, and then integrate it with ProcessWire. My thinking here is that the majority of people who know how the basics of HTML and CSS will be used to working with a template of some sort and will want to integrate it with ProcessWire. That's an idea anyway. It's certainly my starting point for any website - built the template in HTML and CSS and then integrate it with the CMS. The start of the book needs to be thinking of the chapters and contents of each chapter and build it from there. Once that's decided upon you can fill in the pages - easy I agree that linking to PHP.net pages is a good idea if we think there are areas that people should or would like to read up on more that they get linked to in the sidebar or whatever.

I dislike BigCommerce solely on the grounds that I used Interspire Shopping Cart (the self-hosted version) where they treated us all like crap and strung us along for a couple of years with too few updates, show stopping bugs in many releases and eventually abandoned us to make more money on BigCommerce. Their forums were the polar opposite of these forums which just shows you how much of a difference it can make when you listen to your customers and aren't solely focused on making big bucks no matter the cost. Long story short (too late) I wouldn't trust them not to get distracted with their next money making scheme. Their forums (which I think are closed to non-members) are a damning assessment of their disregard for customers (by they, I mean management - there were some excellent support guys in there who were sadly stuck in the crossfire). My rather negative post here is nothing compared to the content of those forums so steer clear would be my advice.

I'd like to nominate myself as an idiot involved with the book In what capacity I'm not sure, as I often fail to finish what I start in a timely manner when it's not generating income. I have InDesign which I would see as essential to getting it into a publishable format for PDF and print, and I'm sure there must be a standard page size for both Europe and US (thinking ahead to getting copies printed on an as-needed basis using online publishers). I think this has digressed enough to warrant its own topic. Perhaps simply a Documentation forum would be a good idea that's purely for discussing documentation and not getting mixed up with the Tutorials or Getting Started forums - just thinking there are a lot if discussions to be had around writing a book!

I want a full-blown "Getting Started with ProcessWire" manual. I don't think I'm thinking too far ahead either - take a look at the MODx manual for example: http://modx.com/learn/modx-books/modx-the-official-guide/ - anyone who's used MODx can see that by looking at the contents pages it covers each aspect of the system nicely. I daresay that a similar approach with a PW manual would be easier to write since it's easy to use and explain - I also wasn't joking when I said somewhere else that Joss' overview of pages should be the first page anyone reads. In terms of what documentation would be useful, I honestly think it would be sensible to think of it in terms of a book that takes you from complete beginner through to basic and intermediate examples. Once you get into the advanced modules and scenarios you're often outside of the scope of normal documentation as you'll be talking about something very specific and that's where the forums help immensely. Perhaps with enough advanced tutorials there's scope for a second manual for advanced usage? I'm all for the idea of a manual that's downloadable via PDF and that can also be bought online pre-printed. What do you guys think? Sorry, going way off topic now Should we at least think about a contents page to get the structure of what people think is useful to learn in one place? (Apologies if this is already on the WIKI - typing at speed on my phone).

It'll be because $page is always the current page array so I'm assuming that diogo is correct and you're echoing $page->body somewhere below that and it's getting confused. Your solution to change the name is correct of course - it was just getting confused as you were causing it to interfere with the original pagearray for that page.

Funnily enough I was thinking that this would make a good module the other day. There are instances on larger sites where you are likely to have many templates and not add other user roles til the end, so a permissions matrix would come in handy. Where I think it would be even more useful is in conjunction with the module that allows you to give per-page access, but every time I think about how that might work I get a major headache. I need to mock up some examples of how this might work. A template permission matrix is a far easier prospect by comparison.

My fingers must be like sausages today - so many typos on various forums

Hi folks Anyone who's tried logging in for the past hour or so will have seen a message saying we were upgrading the forums. Unfortunately everything that could go wrong did go wrong, but I've put everything back to how it was now and you can discuss ProcessWire once again For those that are interested, what worked fine on my local copy simply failed to work when I tried merging it with the liver version here - something to do with the merging routines in the new version of the forum software and/or something I've overlooked. I'll re-visit it at a later date and, having learned my lesson, I'll try and get it working in a sub-forum on the live site before taking the forums offline again. Apologies for the interruption!

I agree with pretty much all of what he says and wonder if we should be checking for any topics with zero replies? I could run a query sometime next week I suppose (busy this week).

Well that would depend on your time, but what sounds silly to me is porting it all to ProcessWire as an "alpha" which would work perfectly well, then translating all that to an entirely different programming language which presents different problems - you're essentially first building it on a framework that helps you in certain ways, then throwing it all away and writing it from scratch, including all of the user and page management features etc that ProcessWire gives you out of the box. The short version of all the above posts is: You will likely need to rewrite most of the code in these modules You will need to know how to do this yourself (i.e. have a decent grasp of PHP) You will need plenty of time to do it all in - I say a year as if this was me working on this for myself and not for a client I have time constraints during the day and less time during my evenings and weekends that I would be working on it. Either way it's no small task you're embarking upon and there's no easy shortcuts to getting there, but ProcessWire is a good system to build many web applications in Doing this all and porting it over to Ruby as a version 2 sounds silly. Stick with one or the other from the start. EDIT: In fact your last question is worrying - combine ProcessWire's flexibility and UI with Wordpress? That is also frankly silly. At one level they are both CMS' (Content Management Systems) and duplicate each others' work, though ProcessWire is arguably the better choice, certainly to those of us who use it. What you are suggesting now in terms of a car analogy would be called a "cut 'n shut" in the UK (and probably elsewhere) - taking two halves of different cars and welding them together. It's possible (illegal in the case of cars ), but... why?

Now I'm stumped. So you're going to port a lot of apps over to ProcessWire from WordPress and, if that wasn't going to take enough time (several months of your time at the very least, if not a year), you're going to ditch it eventually and port the whole lot over to a completely different programming language? Are you sure you're not pulling our leg with this because I've got little time for jokes that waste people's time here. Not trying to sound nasty, but what you're suggesting sounds a bit silly and that's just the way it is.