Joss

I have just finished the first draft of a new tutorial on the wiki. http://wiki.processwire.com/index.php/Basic_Website_Tutorial I know it needs tightening a bit and possibly some more screenshots, but my main concern at this stage is whether it works technically; in other words, if someone follows it, will they actually end up with the finished site? The aim of this tutorial is to go further than the Planets small project walk through. It starts post installation by cleaning a few things out, adding a couple of modules and so on. It then creates a site structure from scratch, creates a site settings system (site title, banner, meta keywords and so on) and populates the new site structure with the results. Finally, it creates a new article template with new fields and adds the page. The idea was that I could cover in basic detail: How Template Files relate to Templates Creating various field types (including images) Getting information from the current page and another page (using $page and $pages) Talking about a few other concepts like how information is stored Demonstrating the power of not having a templating system by default And lots of other bits and pieces. This tutorial produces a demo site that is ready to accept other tutorials - slideshow, news system, etc - without having to start from scratch again. The site design does not use a framework, and is simple and clean but familiar - could be the basis for many site types. Anyway, initially I am just looking for comments on the technical side. So, if anyone has time, can they try it and see if they actually end up with a site, or have I forgotten anything? Bearing in mind that I am very new to PW, I could easily have got things wrong somewhere. Once I am happy that it actually works and that I haven't said anything in it that is technically wrong, then I will go through the writing with a fine tooth comb. Thanks in advance to any guinea pigs out there! Joss

ooh, I will go look at this in the morning. I am proofreading my first tutorial at the moment and it is making my head hurt.

Okay, shot through the General Support (30 pages) I found a few that were moved topics, 5 others where the poster had answered their own question and one that I answered for fun. (See Diogo's post above) The ones where they had answered their own questions were from experienced users. I did not find ANY in General from new users that were unanswered. Oh, there was one. It was "post your questions here" from some bloke called Ryan back in December 2010. I wonder what happened to him? Probably went off and used Joomla.... That is a pretty good record! One very impressed Joss

Personally, I think form design is a constant accident waiting to happen. Have you got a screen shot of what you are talking about? I think I often favour the wizard approach where the first page of the wizard has all the mandatory stuff. Though a cleverer approach is to allow some one to save a form with empty fields, but not allow publishing in that state. Is that possible in PW, by the way?

Interesting idea this, because even really old posts will come up in google searches. It is a horrible job, but it would be interesting to go through the list and put a quick answer even if it is just pointing the thread to a more recent thread that covers the same subject. At least that ties up some loose ends. Damn good PR! Assuming anyone notices, of course.....

So do I, which is why I am trying to give back. I am not a programmer so I cant help with the development, but I am a writer, so I may as well give a bit of time to the docs. Mind you, the lack of being a programmer may be a touch of a problem there as well, but at least I have people here to ask (Which is more than I can say for some other application forums....)

Hi Boundary Perhaps I was being a little flippant ... sorry. It is my advertising background getting in the way again! Yep, put it in the forum wishlist, assuming it is not already there - worth checking.

Put it in the Wiki? In the longer term I think there will be a proper documentation system based on PW. But for the moment, the Wiki is an excellent collecting and collating system to start getting what is needed down on paper ,,, er, as it were. Ryan is away for a few days I believe, but any that do not have a wiki account can ask him when he gets back. Joss

If in doubt, go down the pub - worked for me for years till my liver pointed out a few rather obvious problems with the theory.

Yes, DaveP has the right of it. Apart from being courteous and helpful by replacing the content with "This content is no longer available, however, you may be interested in these related articles ..." or something along those line, you can also leverage the visitor who, after all, has landed at your site. You should do something with them! This is good marketing practice dating back long before the internet. When readers would write to Magazines or Publishers asking for an old article that was no longer available, the standard practice was to send them an apology and enclose a recent copy of the magazine as a consolation. One new reader and satisfied customer. This response felt personal and direct - it felt much more than some automated reply (even if, in reality it was not far off being automated for the day). Modern internet publishing has huge amounts to learn from the print publishing industry. Joss

Well, that got my dog's attention! She prefers the contents to the skin as well.

I know it is meant to be bad forum etiquette, but I like threads that wander everywhere. I know it makes them hell to search and difficult to keep track of, but they reflect how people think in real life, how they communicate - and that is fun! Back to the subject, having isPublished would be a useful test to have floating around. To expand on that, I wonder what the possibility is of expanding states and the resulting checks in a custom way? For instance, if you create a very complex news site with proper newsroom style editorial control, an article could have a lot of states - draft, in editorial consultation, submitted to desk, returned to author, notated for editing, submitted for copy, marked as approved for publication, in pre-pub editing, published, archived, rejected, referred to legal .... it can get interesting! Obviously, for 99.9% of the time, you don't want all those cluttering up the system, but some might like to add states in their own installation/site profile. Perhaps these can all be handled by a module which would allow a bit more versatility .... Joss

Specially designed just for you

Soma, I agree - and however a manual is laid out the point must be made that there are alternatives, without listing so many that it becomes like wading through treacle made of skinned cats. Umm ... one metaphor too many, me thinks.

Which begs the question, which sort of website? From the planets tutorial you can see how to create a basic sort of website, but what if you want to add a gallery, or create a contact form, what about meta data? There are a lot of variations and it would be difficult to guess someone's priorities. So, how about this? Stage One So, you start with a fairly agnostic site with a header and footer - incredibly simple framework with a masthead banner, menubar and common footer with text and a logo in it. Dump the side bar for the moment - it is a distraction. So you would want to cover getting rid of stuff you dont need. Also, do some housework like change the name of the admin page, add a couple of very useful modules (crop image, module manager,repeater, etc) iand update the JQuery for the front end of the site. Next create a site settings template (without file) and page combination for site name, site meta keywords and description and a top banner image and demonstrate how to pull that data into your header and footer. And then you edit the home page information just to make sure it works. That is the intro. Stage Two - well, lots of stage twos After that you can fork out with child articles. Each one can cover one scenario: news page, contact form, team page, Flexslider show, and so on. Each one must fit into the site created with stage one and must not conflict with the other child articles. That way, users can find their own route through this based on their own priorities rather than having to wade to the bit they are interested in. As an offshoot, it would also make clear some good ideas about how to manage a site as it becomes more complicated by getting the planning at the beginning right. This is a good way of getting some new website people in before they go and weld themselves to Droolapress (see what I did there?) while saying to more experienced users, "we know what your most common tasks are, so here they are, ready to go." Joss

Collage perhaps? Anyone with a kid doing art needs a project??? On a slightly less zany note, maybe not a bad idea to redo it as a series of nicely laid out and branded PDF pages that people can print out. I still find the old fashioned type of manual (you know, the one with that paper stuff and pretty covers) the best thing to use for most things. After a while, even in the biggest manual, you can instinctively find the right page just by how much the corners have turned up. Hell, in a really trusted and well used manual you can find things by smell and coffee stains alone! I have yet to find ANY software based system that can replicate that level of super-personalised interactivity. Joss

Nice site! Though I am concerned about mixing the idea of a Dentist and the phrase "ProcessWire strikes again." Makes my teeth ache (the few I still have)

I personally think the Cheatsheet should be made into a nice tea-towel that I can frame on the wall. Just a bit on docs - the ideal (for me, at any rate) would be to have the cheat sheet, complete with its short hand explanations (which are good!) and then a link to a longer explanation and real-world example or two. If anyone ever writes one anything for any of the items on the Cheatsheet, stick it on the wiki, or send it to me and I will stick it on. That must have been fun! (And potentially a bit of a shock for the unwitting....) Joss

Hi Soma I am using your Teflon theme and like it! The only thing I have problems with (which is to do with the underlying admin side, not your theme) is going backwards and forwards between areas. Some very simple things would help, like a Save and Close button and a Save and New - especially for mass field creation or mass page creation. But also having access to the fields/pages/template list while still on an edit page would be nice - either to just leap from editing one thing to editing another directly, or even opening up another edit page in a new browser tab/window. I think admin interfaces should always be heavily customisable so that several very different interface layouts are possible - not just themes. That also helps with legacy issues. A new admin layout might be wonderful, but if the client has been using the old one for a couple of years, they may be less than impressed with changing. As was said earlier, there is no best way, but there may be a better way for one particular person and how they think their clients will work best.

Hi Diogo. Yes I thought of something like that - or actually a bit cleverer. So by default you would have the standard, fixed width tree. When you mouse over it it expands to accommodate any longer titles if needed. As you expanded the tree it would also get wider to fit the wider tree. When you went back over the edit area, it would go back to standard size. Optionally, you can hide it entirely. That way, it is there most of the time, but not taking up too much room. Another thing that should be switch-able is whether when you open one part of the tree, other parts close. When you only have a limited number of pages, you may want to expand several parts at once. But when you get to a large number of pages that would be simply impractical, so you would not want that. Also, is there a problem with loading links to thousands of pages at once? Would you need to load the tree in bits so the entire page did not fall over? Joss

Arf'noon! The confusing folder/tree system is actually a bit like windows folders in list mode - but in such a way as you can still see the top level to speed up going back to source. Another way of doing that is by having top level items as a drop down, plus a live search area. It is the old problem of what happens when you suddenly have 10,000 pages in goodness knows how many trees and you dont want it taking up much width? I get the feeling that there is a clever way of handling this that we haven't thought of yet. Joss

Category Update The one interesting thing about posting even a couple of tentative articles on the Wiki is that it has made me evaluate the categories from the point of view of Browsing rather than searching. I something think Wikis rely too much on searching, which assumes people know what to actually search for! Basically, there is one top level category - Processwire. Then there are some main categories. These first five are the most important: Fields Templates Template Files Pages Setting Up Just about everything will have a home in either one of these, or in a sub-category to one of these, for instance Fields > Field Types. The I have some other main categories which are basically cross referencing: Processwire Concepts Long Tutorials Short Tutorials Code Snippets Useful JQuery Template Frameworks So, an article that is about pages and is a long tutorial would be put in both Pages and Long Tutorial. Since articles can belong to more than one category we might as well make use of that to help people wander through the docs. The key, I hope, is the first five categories. Basically, when you first start (and even much further in) your next question is probably about one of those 5, especially the first 4. So, going to one of those categories will display a list page pages and sub categories that will light up your world! Or, at least turn up the wick a little.... Joss

I have not dug into the admin theme possibilities much, however, I have a feeling that what I am thinking about is not possible without treading on the core rather a lot. I like the fact that the admin is very straight forward, but I do get lost from time to time. By that I mean That if I work on something like a field or a page and want to play with a different one, I have to get back to where I started rather than jump from one to another. My thought would be to have a top bar with the main links, just as now. But when you go to pages, the page tree is in a left sidebar and any pages you open to edit are on the right main pane. This means that visually you always know where you are. The problem is how to incorporate the rather nice moving of pages and things like bringing up "edit view new move" and so on. One possibility is to use Jquery to create a right click menu on a page item - that would probably get round the problem and would allow for more options that might appear in the future "archive, email to my granny, feed to the dog, etc" Where sidebar trees run into dificulties is when you have lots of sub levels and it gets wider, or someone has a really interesting long title for a page! The way things like PhpMyAdmin do it is simply to add a horizonal scroll bar - which I hate, to be honest. May it is better to have it as a sort of mixture between a tree and navigating through folders. So you would have your top level pages to start with. If one has a child, you can click on its "open children" icon and the menu is reloaded with that next level. Top levels are still visible, though slightly greyed out. There is no indentation. If you go to a sub-sub level, the same thing happens. You see the list in the sub-sub level, but you still see the other Top level items (not the sub level, perhaps) This does not give you complete vision of everything, but it is probably manageable, especially if you have a lot of sub levels and a lot of pages. Titles possibly should be truncated. I am a great believer in a two-title system anyway. One for list sorting purposes and another one (or more) for displaying on the site. The same navigation system would obviously be used for Fields, templates, modules, template files and anything else that might appear in the future. Anyway, that is just some idle thoughts before bed. Joss

Diogo - That is a very good point! Thanks Apeisa - Yes, I have been using for blocks in boostrap templates, but I agree, it is better to be more focused and pull specific information in other uses. I suspect that the "Pages" section of the Wiki and any subsequent manual is liable to become the most complicated and thus, the hardest to understand. It really needs to be broken down into specifics - use this for this situation - so that users can make a really good judgement on which way to go. Perhaps it could do with a sort of Best Practices article that lists the methods without the fine details so you can browse through and say "that is the sort of thing I want to achieve" and follow the link through to the detail. You guys up to helping on that? Joss

Thanks Martijn Okay, so there is a relationship there. If it is moved from /blocks/ it will break. Which reinforces the point I am making that unless this is part of your template structure (for some reason) it is better to pull a page in via a Page Field so you are not messed up when it moves and you can change the source page easily. Ta much! (PS: Last time I met someone called Martijn, I wrote a whole pile of music for his fantastic animations for the Dutch government. Good money too!)