Joss

You might also want to look at Liferay There are two versions - the community driven one and the supported EE version. The latter has a longer developement cycle, is quite expensive, but the support level is very high. The community one is more bleeding edge and does get used in a lot of projects. Liferay allows you to create a complete organisational solution with multiple websites, user groupings and so on. Each "site," which can be public, restricted or completely private, comes with fully developed forums, wikis and blogs, as well as a CMS for running any internet/extranet system. There are also a lot of plugins to increase social interaction and a hook system that allows you to link it to other databases or systems. All its functionality is based around Portlets (their versions of plugins) and there is an ide running on Eclipse which helps in the development of hooks, portlets and themes. Although it is a java solution running on Tomcat and others, portlets can be written in a variety of languages including PhP. It might be worth you looking at, but one warning: it is a bit of a huge beast and you will need to find an experienced developer if you want to do anything clever with it. You can download the community edition and run it as a stand alone locally to play with - it comes complete with the tomcat server and all necessary bits. Having said all that about Liferay, PW is a hell of a lot more accessible and much, much easier to develop with!!!

Really like the site. I have been thinking about one page websites - how do they work when it comes to SEO? Is the lack of pages and internal linking a problem or is there a work around for that? Showing my ignorance here a bit!

Sorry, I should have said FrontPage 95 Or Corel Webmaster Suite

Managing the Hierarchy could be fun, and I think PW default page structure is perfect for this, though I think a novel way of displaying it for management purposes might be worth investigating. If you look at it, it is a family tree with Home at the top and then departments, followed by subject, followed by shelf followed by items, just like in a library. If someone was clever, they could put together a JQuery tree that displayed to the Shelf level, but then changed display when you wanted to list everything on the shelf. For browsing/management, you simply work your way down the tree. At any point you can open the entire list that is beneath that point in the tree, or you could work your way till that branch runs out of twigs! Yep. its a TwiggyPedia! (Sorry ...) So, that is the standard way of laying it all out. But it is not the only way, and there is an argument to say that several ways should be employed all at once. The standard way is the equivalent of wandering into a library and looking around, heading eventually to the shelf that interests you. However, behind the scenes the library uses a different method like the Dewey Decimal Classification http://en.wikipedia.org/wiki/Dewey_Decimal_Classification These types of system use a number that is unique to each book and is based on category and other criteria. In libraries it makes books easier to return to the correct shelf, but of course in a digital wiki can be used for similar purposes. Moving on from that is tagging. Now tagging is often seen as a flat relationship between otherwise non-related items, but I suppose it could also be hierarchical if the tagging system was. My unformed theory here is that people are often inaccurate with their tags. If you do an article on Richard Branson, you may tag it "Entrepreneur" and "beard" But, is this very bearded? A bit hairy? ZZ Top? Time for a thesaurus! So, why not have a tagging system that is based on a thesaurus. You type in Beard and you are offered a choice of similes - stronger ones at the top and weaker ones lower down. If you choose a weaker one, you could choose to dig deeper. The result would be tag trail, starting with your first thought and then listing how you went from there. If you weighted them, then the tagging is becoming hierarchical - you could choose to look at other articles that shared strongest tags or weakest tags. Other categorisation can be geographical and of course time - WHEN is this about.(as opposed to when was it written) Now your wiki is becoming truly ordered

A bit of an aside here. When it comes to interfaces and accessibility, I think there are two distinct areas: Editorial and Management. Management would use the back end and would itself be subdivided between Administration and Print & Design Administration would simply be everything to do with the application - updates, modules, and all that. Print & Design would be about the overall look of the web publication plus (for more controlled applications like news sites) final formatting and layout. Print may also have final publication control in some environments. On the front end it is all about authorship and editorial. The front end can be subdivided as required with multiple editorial roles, author roles, librarian roles and so on. Even legal, if that was required. This seems over complicated for a wiki. However, allowing this sort of division of labour and roles at the outset does not mean that you cannot disable much of this if you want a simpler version - easier than somehow trying to add stuff later.

I think the database bit is less problematic. If you work from the fact that academia is about "bits" of information put together in such a way as to make a coherent argument, then that is pretty much the way processwire works anyway - far more so than other systems which tend to take lots of information and shove it together with separators on a row somewhere. Possibly economical, but doesn't make sense. If, however, you were creating a specific site for dissertations for example, for each you would have distinct blocks (fields) for Title, Long Premise, Executive Summary, Content, Chapters, Index, Bibliography, Author, Copyright and so on. Since every dissertation works in the same way you now have very logical blocks of data where you can ask very specific questions like "list all works where piglettes is listed in the index." Now, that sort of breakdown is very familiar to any PW user and I think is a really useful starting point. So, I think the starting point has to be to ignore everything that has been done in the last 10 or so years and go back to the origins - look at how things like the British Library are organised and curated, look at how something like the London Times works, look at how a printed magazine works .... Basically, look at how a potentially large body of work needs to be managed and the come up with a system that fulfils that need rather than rewrites the rules. I think there is an additional usage - a lot of people use mediawiki and others as a sort of communal knowledge base as part of a project. The problem there is that there is a disconnect between the knowledge base and the project itself which helps no one. It would be interesting to find a way of bridging that gap. For instance, I like the idea of comments within code to become searchable notations within a knowledgebase so you can search for specific functionality via comments and not just by knowing what the function just happened to be called. Anyway, I am wandering. I think what needs to be nailed down is the non-techincal how things should be submitted-stored-retrieved and from there working out how that can be realised using PW.

Ah, yes, I was sort of thinking that you did not have a folder per image - this is where my tech knowledge is not good enough. Obviously, the actual behind-the-scenes bit needs to be as efficient as possible, but it would be nice that somehow all information from the database point of view is treated in the same way, The other field(s) you need for images is their metadata, which is easy enough to extract on upload. It makes sense to extract this from any image since it will often contain copyright info, geographical information and so on. Useful stuff and can reduce form filling if available. You can also make it a restriction - a very tightly run library would not want images that did not have the required metadata and would abort the upload. It is one of those twists that though many would not use it, makes for a complete system Edit: There is also the ownership route of all information, whether that is text or image. The system should show what article the image has been used for, but also who uploaded it originally and on what date. Again, although not important for many applications, this sort of audit trail is needed for more academic use of a wiki. Edit 2: You are right about how wikis are run as opposed to should be run. I think there is an argument that says if you make something where anarchy can exist, inevitably it will exist. Perhaps there should be the option on installation that says "I want this installed with full publishing rules" or "I want anarchy." If the former, then editorial controls, review before publishing, proper categorisation and indexing are all enabled. It becomes a highly controlled, properly managed environment. If the latter, then it is more like Mediawiki.

I agree with that. The thing about a wiki is that it is trying to emulate a library (not always very well). ProcessWire has a base structure based around one idea - the page. That is extremely useful if used for absolutely everything. Interestingly enough, the one thing it does not use it for automatically (as far as I am aware) is for an image. From my brief look, Soma's module is trying to do that - make an image into another page entry. That makes perfect sense. If images were always actual page entries (in the same way that repeaters are pages really), then the categorisation system is there by default and PW's native hierarchical system makes the perfect image library. Really, that is probably the starting point of a wiki built with ProcessWire - Everything entered or added is a submission to the library, whether that is text, a media file, an annotation, a comment, whatever. In our language, everything submitted is a page in our hierarchy. That is a very powerful starting point. From there, the next stage is not the interface but is to look at it from the librarian's or curator's point of view. How is each page categorised? How does it fit within a hierarchy, how is it accessible. To a certain extent this is not an internet thing, this already exists in bricks and mortar libraries and is a well tried and tested system. After that is all properly sorted, THEN you can have fun working out the perfect interface to allow submissions to the library to be made in a very accessible manor that is completely agnostic - the final data being stored in the way the librarian needs rather than how the interface presents the data.

Do you see this as a profile or a module? One thing about profiles which is slightly awkward is if you want their functionality added onto your existing installation. Where as a module could do that exactly. Though with something that will add fields and templates, then there has to be some basic questions asked in installation: 1. Do you want this at the root of the site or under a parent? If the latter, name an existing page or one you would like created. 2. Are you using any of these field name? wiki_body, wiki_summary .... This is to just check since if we are dealing with clever markup situations, then the fields used will probably be pretty specialised. Also, it would need some clever image management system since if Wiki's are about sharing information across the system, then that has got to include images and other media. I did at some point come up with the idea of a clever image system, but can't remember what I did with it! It was using pages, but the idea was that each image had a record of which article it has been used by rather than being kept in an article related directory ... something like that.

Indeed, they can have all the same fields and you can associate any template in the backend with a different template file

Er ...I think this is a case of multiple templates. So, each City would have its own template and then you can give the permissions to each of those templates. The children pages inherit permissions from the parent template. You would need to try that to see whether all the children having the same template but different parent template pages get their permissions logically - I think they do.

The parsing is a big issue. I noticed in the liferay wiki that they have either creole markup or html with a wysiwyg - however, they are not properly compatible with each other, so when you choose one system you cannot leap over halfway through the article. Here is a mad idea. Every field is actually two or more fields - one has the text in it and the other the markup. So, you decide to write a paragraph with wiki markup. The text is entered into what looks like a text area. You tell it you are using wiki markup and then go ahead. In reality, two versions are stored - one just the text and the other the markup, or text plus markup perhaps. If you then decided you wanted to do it html/wysiwyg - you can tell it that. It converts and creates a new markup field, this one with html in it. You then edit and save. Any text editing is saved again in the non-markup field and any mark up is stored in the TWO markup fields - html and wikimarkup. OR - Any markup is stored as something like XML and then converted into whatever markup for the desired UI in memory on the fly. Possibly better that, if you have a chunky enough server. This way you can allow people to edit in as many ways as you create converters/interfaces. The markup always ends up usable and the original text is always clean and intact. The user is only presented with one interface at a time, of course. I quite like the idea of messing around with repeat fields for content. So, you would write your article in blocks (paragraphs) - each would have a title field (optional), the text area defaulted to whatever your preferred editor interface is and an image upload. You would have to mess with the user interface to make it look continuous rather than like a blocked form. This is my thing about data integrity. I like the idea that somewhere in the system the text is sitting there in as clean a form as possible and does not require the system to be working to view it and understand it. So in 500 years time, it still makes some sort of sense. I agree about word, but I think you would stick to modern versions - there are limits! (Edit - this is a bit like using Lightroom where all your photo edits are stored in a separate file and applied when viewing)

Ah, you have touched on a complete bug-bear with me! I absolutely hate mediawiki and its associated programming ethos - it alienates the very people who need to use it, highly intelligent knowledgeable and very busy people who do not want to learn something new! In practice, a wiki is basically just a knowledge base and as such can fall into two categories: Extended FAQ / User Guide Outside of Wikipedia, this is how it is most used - the PW Wiki is a prime example. This type of system works best in a strict hierarchical way - so, one person puts together the structure and every body else adds content. The hierarchy could (and should) be defined in many ways - categories, book content (menu structure), index, tags and so on. So, a true user manual. In this case, it is also best that contributors are restricted to how information is added and prompted for certain types of information. I like the idea of blocks of information here. The most basic block, for example, would be title and any categorisation information. The next block would be a summary. Another might be a Question or Proposition. Bocks would be available for body content, sidebar information, cross linking, graphs, financial information, citations, news links and so on. It would be up to the administrator to decide which blocks are available for users (or groups of users, perhaps - see editorial below) This sort of prompting and division of information means that consistency in content can be imposed - it is easy to make things LOOK the same, but making things READ the same is harder, especially if you give people a free for all system! Enclylopedia Wikipedia is the obvious example here. The point of an encyclopaedia is that it is a reviewed and edited collection of authoritative articles written in the style of a named contributor. This means that the publishing system has to be very accessible to the contributor - whether that is in a free-for-all system or a traditional editorial system. A member of my family who is a retired, noted professor, pointed out that he would contribute to Wikipedia if he could somehow just upload a Word document. But he has absolutely no interest in learning wiki markup and he finds the new (easier) system also confusing. He is a scientist too. He has a point. If you want a system where anyone can join in, then you should offer them a range of ways for them to contribute - the publishing format should not be their problem, but the publishers. So, no wiki markup, intuitive toolbars with nice big logical buttons and the ability to upload and convert source material (even if some fiddling needs to be done following import). Again, additional blocks are useful - not just as tools but as prompts. Editorial This is one thing that make a system much more useful to a wider range of publishers, as it were. One of the big differences between a CMS (as we know it) and a news system is the editorial hierarchy. Years ago I wrote my own CMS using Dreamweaver and the addon mysql tools. The editorial system allowed for: Full editorial hierarchy including section editors, photo librarians, managing editors, staff authors, freelance authors etc Article control - Authors wrote articles, then submit to an editor. Editor reviewed and could publish, archive or send back to the author for amendments. (Editors could also set an article to be reviewed by another editor if they needed help) Shared Authorship - an article could be written collaboratively or by just one author. Library system - research notes, images, contacts and so on could be put in a central library and access controlled History trail - everything from who reviewed what and when Legal - additional layer for legal review. Basically, if an editor marked an article for legal review, no one could publish until released by the legal team. So, all the people and systems you would expect in a newspaper office or publishing house applied to a web system. This might seem OTT for a wiki, but it is a logical extension and having the foundations of such a system built in at the bottom means it can be extended easily later. Output This is, or could be, where PW scores most highly. It strikes me that the output should be in small, simple blocks that means that someone can throw away the supplied template(s) and start from scratch using a very basic API - probably a set of function includes for things like lists, and then just the normal PW bits for most of the rest.

(Note: Teppo typed faster than me, so I am repeating some bits here) HI Adonis And Happy New Year back at you! Okay, let me answer the bits I can. First, template. Basically, ProcessWire does not have a templating system of any sort, so you do not have to learn anything. In the /site/templates/ directory, anything with a php extension is regarded as a template. So, if you create a file called myfile.php in that directory, you can then go to Setup > Templates in the admin and add it as a template. (Click New Template and you will see it listed.) You can then create a new page using that template. Obviously, as it is has no mark up in it, nothing will actually get displayed, but it is a start. To use it more fully, you just need to write HTML in it (as you would a stand alone html page) and then add a bit of processwire php markup to output the fields. For instance, the Title field would have automatically been added when you added the new template in the admin so to out put it you could put in your html, for instance: <h1><?php echo $page->title; ?></h1> The main thing is to understand the difference between a template and a template file Template: A processwire object that associates a group of fields together Template File: The file where you put any markup and/or logic for outputting those same fields. You should go and do this over the top tutorial and it will all become clear! http://wiki.processwire.com/index.php/Basic_Website_Tutorial CK Editor Since this is an add-on module, you can do pretty much as you like with it. However, there are a couple of plugins added to it (for images and links) that are customised for processwire that need to be left intact. PHP Knowledge I have very little php knowledge, but PW has proved a really good way of learning the basics! So my knowledge has increased using it. Make sure you learn about the basics of using echo and how to do a foreach loop. (plenty of examples in this very forum) And then read the API, especially the cheat sheet. That will do you for now - go play!

Basically, since Processwire does not have any theming engine, the trick is to just do what you like and add the ProcessWire API to output your data ... pages, that is. So, as Martijn says, just install PW, chuck out all the bits you don't need (fields, templates and so on), and then just think about it like writing a bit of HTML. In fact, just write some HTML. You can use any framework you like - Bootstrap, Foundation, Adobe Edge, Frontpage 97 ...... You can use any Javascript/Jquery functionality you like. You can use any anything you like. Since PW does not have anything in the front end, you cannot conflict with anything unless you create the conflict yourself True freedom! That would be "Free as in ProcessWire"

So, they also build skyscrapers???

This is where I put my hands up and say I aint a tech! But, isn't it usual to do this the other way around? In other words, write a script that runs in each of the clones and looks at the master and does a file compare, then updates if required. So, pull the new bits rather than try and push them.

Yep - you hum it, I will sing it

Hope you had fun! Happy Easter

I started playing with these things about a year ago and sort of got bored. It seems to be solving a problem that doesn't quite exist, at least for the lone worker. I can see more advantages for collaborative projects, but then, things like GitHub seem to work pretty well for those - at least it allows separate experimentation and then pulling successful elements together. Personally, I still use an old PC as a dev server with Virtualmin and Samba on it, and I have just added WD My Cloud to the home network (which is accessible from the web) for other bits (There is a 4-bay, raid version now for people that want extra safety). That way I can hop around editors and IDEs as I fancy, Also, the faster everyones connections are, the less of a pain it is sending stuff to clients rather than archiving centrally somewhere for them. It seems that clients always manage to have problems with things like Own Cloud or Ajaxplorer, however carefully I set them up. Often easier to either email something or just bung a zip up on my server.

I keep misreading the subject of the thread as "New Milktops webiste and BAND" Which sort of puts a whole new spin on the project. When you auditioning for musicians?

This is probably plain silly, but have you tried re-transfering the file/folder again? Just in case it has dropped a byte or two somewhere on the floor ...

Very nice mate!

Hi Teppo, not completely sure since I changed what I did, but I think it was: https://www.google.co.uk/maps/preview#!q=3+Third+Avenue%2C+Victory+Court%2C+Bletchley%2C+Milton+Keynes+MK1+1EW&data=!4m15!2m14!1m13!1s0x4876553b7cb2cb95%3A0x169f00ba52fb4893!3m8!1m3!1d5938539!2d-2.3278149!3d52.8382005!3m2!1i1680!2i924!4f13.1!4m2!3d52.0036453!4d-0.7359115

Mind you, as the evening wares on, it is more like $drinks->FIND("category=whisky, type=middletons, ice=1"); foreach($drinks as $drink) { if($drink->copper == 1) { echo "Sorry Ociffer!"; }else{ echo "Taxi"; } }