Joss

Yes it needs that sort of clarity - perhaps with a little nag at the top of the page saying "this page is not published for public view" or something neater. There is also the issue of possibly needing to view the page in context before finally publishing. So, perhaps it can have a "preview" button that makes a temporary hidden version of something. Sorry, haven't thought that through properly.

I like this! Completely and unashamedly focused on the photos. Perfect

This is a basic site for a car restorer: http://www.tcfautocare.co.uk/ Its a fun and slightly silly site for people who want to get their old campervan or classic car restored. Since this is a very personal, passionate sort of thing for people to do, I decided that the site should be more friendly and show that the company is as passionate and daft about these old cars as the customer is. Some restoration projects can take years, so it is important to build friendly relationships from the outset. For this reason, the call to action is biased towards getting customers to phone rather than use a contact form. Personal contact is essential. PW 2.3.9 Bootstrap 3 It has a small blog system with a category field that just allows blog posts to appear on the bottom of specific pages as well as the main blog page. So, a blog about Campervans will also appear on the Campervan Restoration page. It has a blocks system (repeater field) for the main product pages (Campervans, classic cars ...) that allows a block to be created and then placed in the left column or right column. The block can have title, text, image, video and will display slightly differently depending on which of these are enabled or not. A block can also be disabled rather than deleted if it is not required at that moment. Photos are mostly by me (the arty ones are mine) All copy (including the two blog posts to get him started) is by me - and probably a bit obvious! All graphics are by me, including the campervan and fiat - took me sodding ages! There are actually three domains - two of them have static pages with unique copy, but all the menu links are through to this main site.

Oh, boy, it is going to be one of those days; I can just feel it in my bones. For some reason I cannot seem to get the office warm this morning; my banjo has bought a ticket for the deep south, my harmonica is buried under the table, the dog has abandoned me and my hands can herdlery tip the wids on tjhos pist. But, this is also the day when I put up a new site for a client. So, three domains - two of them static and one a PW site. All simple stuff. Just create the new database via CPanel, upload the files, change the config file details and hit go! And... Unable to complete this request due to an error. Error has been logged. Oh Bugger. So, we start the debug procedure. Yes, htaccess is there and right. Yes, config seems all sorted. Permissions good. Can link to an assett - so stuff is actually up there. Dive back into config and turn the debug on. Get some strange message about having SQL base table problems or some such thing that I have never heard of before. So, with a heavy heart, I open up PhpMyAdmin and have a butchers at the squirrel. Oh. Ummmm,,,, ah..... Oooops! You know, creating a database is all well and good. But actually importing some data into it can make a whole lot of difference to the functionality of the site! Silly Idiot!

Haven't got any money, but happy to talk through possible workflow ideas to help find the most logical for users way of doing this before anyone breaks their backs coding!

Where I left them ..... I hope!

Yep, me too. On the files/images front, as far as the form is concerned, they are only location/path references aren't they?

Here is an experiment! I have just been playing with fonts, colours and using a bit of jquery to add a few icons and so on. I have gone for open sans and made it a bit more corporate looking, without changing the layout. icons are from the font-awesome, which is in Wire anyway. All I have done is hacked at the main-modern.css file and added to the main.js file. So you need to add $config->adminThemeColors = 'modern'; to the config file to see the colour and font changes. There are no structural alterations, just cosmetic. It probably needs more work, but I have really done it just out of interest and a moment of boredom! templates-admin-experiment.zip

Aww, Soma - you make him sound so lonely!!! Yes, really this module of yours comes into its own once a draft/versioning/something system is in play. Just about everything I do, especially in music when composing, involves creating a new or alternative version, making a comparison against everything else and the deciding which one to use. On versioning, there is no reason why there cannot be a versions table that hold arrayed data that can be loaded back into a form - or something like that. Though (and you will hate this) there is an argument to say that versioning could apply to an individual field - from the editorial point of view, being able to look through an assortment of bits and then combine them into the perfect version is fun. I do this with Cubase - audio recordings are kept in "Lanes" and you can cut and past bits of each lane to create a whole new version. Mind you, it can get mind bending!

Its a good start and is showing that this part of it works and with various fields. It does need to be mixed with some sort of draft/versioning system, I agree, to become a full solution, but that also requires some fairly heft complications: To start with, if you lose connection or something, when you return to the page you need to be offered the choice of the draft version or the published live version. This probably means adding an extra link in the page list actions to open a draft (only shown if it exists) If you are looking at the draft version, then you need to have the option of saving the draft as a draft, or publishing, which would overwrite the live version.

Okay - I am out and about today, but I will give it a work out a bit later. I need to create a new virgin testbed for these things! Right - out into the rain!

Just playing happily with the new admin template (making a gentle colour version). A couple of tiny thoughts: On one of my own themes I have added a "Site" link on the top bar - very useful: it simply opens the front end in a new tab/window. Also, the view link on a page is also useful if it opens in a new tab/window. Other than that, it is looking good.

Hi Soma Happy New Year! Okay, it is now saving, but on my limited test it saved the two text input fields on my page but not the CKeditor (inline). I will do some more tests tomorrow sometime Night!

Well, nothing happened. No saving happened, I mean.

Hi lkossis I tend to create a page in my tree with a unique template that has no file and call it content-management or something like that. Then under there I put all the stuff like selects, tags (sometimes) and so on. I then make that content-management template not accessible to some roles. That way everything is in one place and only I can mess it up!

Okay, not actually doing anything on my test site (2.3.9 - with the new admin template). But it can wait for later in the week (its new year)! An extension to this would also be to optionally save a field onblur. That would be useful for when filling in large numbers of fields, whereas the auto save is good for when working on a single large text field.

Dear Soma I shall rush off and try it immediately A Prosperous new year to you and yours! Joss

I think it depends what you are writing. Since part of my job is as a writer, I know that you can get very much into the creativity of the words sometimes and stopping to hit save on a regular basis really interrupts the flow. When working in something like Word, a simple Ctrl S can be very easy, but on a form, you need to scroll to the save button, mouse to it and click it, then wait for the form to reload. Personally, when on a desk top, I prefer working in Word and then copying and pasting into a form where there is a large single field - for instance when working on a blog post. But that does not work so well when you are working on a form with loads of fields, or want to put something straight into a form from your mobile and so on. I suppose in the end, this is all about making the user experience more streamlined and trouble free, and also reflecting what they are used to using in other instances. EDIT: Oh, and getting closer to the wonderful pencil and paper - no save button there!

Just picking this up again as someone has just asked me about this and I saw this post: http://processwire.com/talk/topic/5236-admin-session-logs-out-when-wireless-connection-has-hiccup/ I think the use of CMSs for drafts will increase simply because the idea of "working in the cloud" is now the new "in thing." Several of my clients (music clients, mostly) use Google Sites for a lot of their project work, and they are very used to the fact that is saves every so often, quietly in the background, with only a small notification appearing off the work area. Also, ProcessWire has the ability (as has been shown by others) of being used as a web application for everything from help desks to sales and CRM to general intranet functionality. In these scenarios, perhaps when you are conducting a live interview on the phone and typing into a PW application, some sort of autosave or draft autosave is essential to save embarrassment or possibly the job. General autosave would be easy enough - the page does not need to be refreshed as you are still working so it can just save in the background. This is fine for a page that has yet to be published (autosave should respect the current state), or for something like a client record or help desk record where there is never a public viewable version as you would have with a blog, for instance. Autosave for updating an existing published article is a little more complicated and probably should be part of a page version system. From my point of view, I would see this as just being saved as simple hidden child pages with some sort of specialised ID that shows that they are directly related to the page for versioning rather than as children for other purposes. Clicking Save as Draft or the Autosave would save to the child. Clicking Publish would save to the main page.

I dont really - I used to use Andy's in Denmark Street, London, but he became more than a bit, erm, untrustworthy and then very bankrupt. This strat is only about 15 years old and I just get it serviced by the local shop occasionally. No idea who this guy is, but he might be worth checking up on: http://www.manchesterguitartech.co.uk/

Er yep - American Custom. My day job.

You need to drill down to the fields, I think, via your repeater field so, Page, then repeater, then pagefield, then field You can also render the whole page output that is selected by the page field by using render() That way you can use the template for the pages selected by the page field to do the layout for that particular little set of fields. Assuming you are looping through your repeat, it should be something like: foreach($page->repeater as $p){ echo $p->render(); } Something like that - I have no notes with me so I am trying to remember what I have done in similar circumstances http://wiki.processwire.com/index.php/Including_a_page_in_another_page

Yep, that one caught me out when I first started playing. Now I tend to do just about everything using functions on an inc file so that my templates are very clean and easy to swap around.

I am

Just thinking about the profile vs module thingy Another good reason for doing this as an addon, rather than a fresh installation, is that a powerful wiki could make up part of a bigger installation that included brochure sites, discussion boards, shops and all kinds of other things. One of the problems with wikis is that they are separated off from the rest of the organisation's web, so there is no cross sharing of data and users. As an addon, rather than a site in its own right, it brings it closer to the rest.