Pete

On a related subject, I thought Wikia.com was a hosted WIKI site running different software than MediaWiki - turns out it's still MediaWiki and related to Wikipedia's founder (see the "Our History" section halfway down this page: http://www.wikia.com/About ). What surprises me is that, for one, that site looks so much better than most WIKI sites, but also from a technical viewpoint what they are labelling in that section as "New Features" are things that can easily be done in ProcessWire - something that gives me hope that the ideas we're mulling over here aren't that far-fetched. It almost seems like the competition have thrown in the towel somewhat doesn't it? The vast majority of WIKIs on the web use self-hosted MediaWiki or are on Wikia nowadays, but as we've said in the CMS field, there could be better alternatives in many situations than the top-billed products. I am of course getting way ahead of myself there. For anything like this to get off the ground one of the first steps is to dissect an existing product (I'm only thinking database and file structure here) to see how they handle things and get an idea of potential pitfalls before we fall in them

I think this is teaching me about how a lot of WIKIs should be run but not necessarily how they are run. Many (or most?) start without categorisation - either because they start off small or because there are no options for categorisation - and then continue down that path which just exacerbates the issue. I sort of disagree with treating everything as a page though purely for reasons of scalability in this case. With images for example I'm reasonably sure that assumptions can be made as to the fields required (I can see people flinching reading this). My thinking is that images on WIKIs will number larger than the amount of pages themselves, so a new image fieldtype with a few extra fields would be more efficient and scalable there. I think I've listed the main fields with title, description, license (if any) as well as our categorisation idea and that's pretty much it. I would tie them to the category pages themselves as previously mentioned. That said, it is possible to do it the way you suggest and then everything is its own page obviously, however you will end up eventually with potentially a million folders in your site/assets/files directory. It's been discussed before here on the forums, but at some point there is the suggestion that the file system doesn't like huge numbers of folders in one directory (really depends on the config). That's a wider issue though and I know last time it was discussed ryan had an idea on that front, but since it's not reared its head again I guess it's not been an issue for now, but for something like this it could become one relatively quickly. Of course, this method allows you to create any content type you like whereas my suggestion is rigid... I think I see which direction we're going to go in as PW is all about having the choice and as long as it's thought about carefully (and things are cached nicely at template level as a minimum) it shouldn't be a problem. More thoughts to follow.

The more I think about it Joss, the more it's like ProcessWire gets it right already for most of this type of content - you usually upload an image for the page you're using it on, and most of the time it's not used elsewhere, so maybe if your pages are correctly categorised you can just use those categories/tags and a simple image manager module (a variation on this: http://processwire.com/talk/topic/3219-images-manager-alpha/ ) to see what images are where and search them for use in pages on the WIKI.

I think it would have to be a profile to begin with as there would be numerous modules required as well as several custom templates. It's not something I would see as easy to add to a site as an afterthought. It is technically possible via the wonders of dependencies to install several modules at once, but the code involved just in getting everything installed, copying templates to the right place and *shudders* making assumptions (like that there are no similarly named templates in the system or templates folder) when copying things to the relevant place put me off that idea - at least in the first version. Usually though, if I was going to write an installer that takes the above into account, I'd make sure to use prefixes in template names and files to avoid overwrites/conflicts - wiki_ would make sense there. The file upload system in Mediawiki is what seems to handle all images and other files. It's simply a form where you select the file, give it a description, select which licensing is applicable etc and upload it, then use the filename to insert it into pages. It's pretty simplistic and would take about ten minutes in ProcessWire to come up with a better version that also categorises files as you upload them - for example you start with a root category, then in the form you specify a parent category (defaults to root) and/or a new category name and on save it checks for these and expands the image tree as necessary. This is another little module idea that means you don't eventually end up with a million images under one folder on the disk. That said, the categorisation you would use here isn't dissimilar to what you would use for the pages on the WIKI, so why not kill two birds with one stone there and use the "tag"/category pages that articles can be tagged against to store the relevant images under? My biggest beef is that many WIKIs seem to end up forming a structure but it is by default an unstructured system. Wikipedia is an encyclopedia, so the first thing you do is use the search, but often WIKI operators (same with the PW WIKI actually) end up structuring a table of contents to navigate through the pages. The ideal is a system that does the latter, but can also be used for the former, so image/file uploads needs some thinking about as in the encyclopedia scenario you would be better leaving images attached to the article rather than trying to store them centrally. I'm getting a headache again

Hi sappel It's still being finished off in terms of front-end functionality which I'm hoping to do the next couple of days, but as the system has evolved it's not going to be something that can be used by others straight out of the box. It's currently very tailored to the specific functionality of the client I'm working with and would require some work to scale it back a bit and modularise it a bit better. I really want to post a video showing what I mean soon but need to get it done first

Something that strikes me is that there are a number of WIKI contributors that like writing in Markdown/Textile/BBCode etc and actually dislike WYSIWIG editors sometimes even preferring HTML (WYSIWIG's get a bit clumsy with tables for example), so a solution should either force everyone to work one way, or perhaps allow the user to do things their own way or allow them to choose their favourite method of editing provided everything is stored in the DB as HTML and each editor can convert on the fly to your preferred editing style. That said, I would prefer to say use this or this - ONE markup-type editing system and ONE HTML editor rather than have too many things to keep track of, given their potential differences. Uploading a Word document is a nice idea as you say, but parsing all the different versions Microsoft has produced over the years could be a headache (they changed it to an XML structure and have their own horrifying version of HTML as well with so much superfluous markup it's unreal!). Either way an editor would almost certainly need to tweak the contents afterwards (but I guess that's part of the job?).

I use those two modules a lot nowadays - they keep me sane

Hi folks Copying this topic from another website where I host a WIKI to get more feedback. WIKI's are confusing to me. They're usually listed as their own software package, however all they appear to be (to me at least) is a content management system with the following features: Page history Easy linking to other pages (links also don't break when pages are renamed??) Page comments with threading (indentation) Contributions from all levels of user (if desired) An editor - WYSIWIG and/or [[tag]] based Spam filter of some form ...? I'm interested in learning what other features make a WIKI software different to a normal content management system. It occurs to me that there might be a gap in the market for something more user/admin-friendly and easier to upgrade. This comes from MediaWiki being a total nightmare to upgrade - they now have an upgrade script (after how many years?) but features get changed or dropped all over the show and you're always looking for extensions to do what should be core pieces of functionality (spam filtering etc) and before long you end up with an installation and a dozen extensions to juggle every time it needs upgrading. There has to be a better way, and I believe we might be 80% there with a basic ProcessWire installation. I'm not suggesting I would attempt this myself or any time soon if I did, but unless I'm missing something all WIKI software seems to follow the same general pattern. From a data point of view, the bit where they tend to run into trouble is that all pages seem to be under the root with no categorisation, which leads to things like duplicate page name issues, plus not the best queries on the database behind the scenes (at a guess). Since everything in a WIKI can relate to everything else, tagging might be better than structured categorisation, as those who use PW's Page fieldtype are probably already aware Also, the caching options in MediaWiki at least aren't as good as they should be - something ProCache would help with (could have everything static and load the user bar via AJAX or something). I didn't intend to start of sounding like I was moaning about WIKI software, but I guess I am If anyone involved in a WIKI would like to fill in some feature gaps from my list above that would be much appreciated. To recap, because I do go on a bit, I would like to know: What features I missed from the first list What features you would like to see in WIKI software I feel like all of this is achievable in ProcessWire with some modules to handle page history (nearly there already I see), users, threded page discussion etc and it's all just a matter of some code to come up with something better. This is just me thinking out loud for now as I've got way too much work on at the moment, but it's one of those things where I've been thinking for a while "surely it wouldn't be that hard to do in ProcessWire" - a WIKI is just a content management system after all.

pwired - see my comment here: http://processwire.com/talk/topic/5208-a-website-for-university/#entry50233 The same thing I say there about forum software applies to shop software - to do something as complex as other ecommerce solutions requires a team of developers or someone with a tonne of time on their hands and probably a year's development time minimum. Not to mention all the headaches you get afterwards supporting a complex codebase (you'd have to constantly update a lot of the payment and shipping modules for example as vendors change their code) and all the other hassle that goes with it. Many other ecommerce packages will have similar if not far more lines of code than ProcessWire to give you an idea, and I suspect it took ryan a while to get to version 1, let alone version 2. You can build anything you want in ProcessWire, but until someone turns up that has no need for an income and also has plenty of time on their hands I don't see a larger solution appearing any time soon. It does all depend on what you want to sell though - Apeisa's module is perfectly fine for a lot of situations and you can easily create a product catalogue in ProcessWire and drop in some Paypal code if you want to do something even simpler and don't need anything in the admin.

Indeed. We all need to cut down our working hours or take more holiday to keep up I had 14 pages to get through too, but I chose to go at it forum by forum, picking topics that looked interesting to read (you can hover over a topic and a little down arrow will appear), then click that to see a short preview) and reading them, then marking the forum as read. Cheating I know, but I have no trouble in admitting I don't have time to read everything any more when it's backed up as much as that

I took the liberty of merging your two forum accounts - the details from your newer one should work fine. I very much doubt a full-blown forum solution in ProcessWire will appear any time soon - the general suggestion is to use another piece of software. This is because forum software is usually really complex, taking teams of developers at least a year to create and years after that to perfect. I know this is why ryan at least suggests using other software for this side of things - see here: http://processwire.com/talk/topic/572-release-discussions/?p=48129 If you've ever looked at forum admins for the likes of Invision Power Board you'll see that there are dozens of pages just for managing them as well so it's not as straightforward as it might seem at first. That said, it is possible to build modules that bridge the membership between forum software and ProcessWire. I've done it myself (and will one day get around to polishing and releasing the module): http://www.strategycore.co.uk - note that you would still manage the forum in the forum admin but you then have available the membership functionality and members and their groups exist in ProcessWire as well. As kongondo says, Moodle is an entirely separate piece of software. I have, in the past, shoehorned several different applications to work together and the results are always painful when you have to update one of them (not usually ProcessWire as the API functions stay the same) but even something like the forum bridge mentioned above could rbeak on a newer release of the forum software as other developers just will not design a good API and stick to it. That's one of the things that makes ProcessWire exceptionally different - ryan has gone for as close to human readable code as possible and it doesn't matter so much how the code works behind the scenes - it could all change behind the scenes (but it won't) and the functions available to you in the templates to pull out the data would still be the same. I think you may need to step back and take a look at what you want to achieve in terms of functionality as Moodle for example already has its own forum module. No offense intended, but you appear to be looking at different solutions, liking the idea of some of them and then deciding you want them all, rather than explaining what features you need. I would suggest that it is actually possible (with enough time and money) that you could recreate what you want from Moodle in ProcessWire and do away with one of the three software packages entirely, then hook it up to something like IP.Board if you didn't like Moodle's forums, but depending on your requirements from Moodle you could be talking about a year's work easily. That said, you can have forums, course modules and site pages all just in Moodle, so if time and budget are your constraints then you could already do it all in one package. There are also dozens of categorised plugin modules for Moodle on this page: https://moodle.org/plugins/

Looks awesome - some really great photos there!

You could also do this: foreach ($pages->get("/tags")->children() as $key => $tag) { if ($pages->find("parent=$page, tags=$tag")->getTotal() > 0) { echo "<ul>"; foreach ($pages->find("parent=$page, tags=$tag") as $tagpage){ echo "<li><a href='$tagpage->url$tag->name' $active>$tag->title</a></li>"; } echo "</ul>"; } } I just threw in the wrapping UL elements, but if you want to paginate the results it needs some more work anyway

Hi there Could you try it with getTotal() instead of count() - click on getTotal on this page as it seems to explain this in relation to pagination: http://cheatsheet.processwire.com/ Hope that helps!

I can't remember how I sized them - I think it was to cater for the various screen sizes but I may have left the thumbs too big at max size - I'll take a look, thanks! All of the language stuff was just from this page: http://processwire.com/api/multi-language-support/multi-language-urls/ Cool Never been there myself, but it looks nice!

There's a little bit of unnecessary code in your original post (and a bit of mixing $page and wire('pages') ) during the first two lines - you could also write it like this if it helps: $tdsphotos = $pages->find("tagsx.title=$page->title, limit=8, sort=-created"); One thing I would like to mention to everyone is that in double quotes you can to this: $page->title but not $page->somepagefield->somethingelse - as soon as you throw in the second -> (I'm not sure of the technical term!) you need to wrap the whole thing in curly braces like this: {$page->somepagefield->somethingelse} or you'll be troubleshooting it for hours like I did a few months back Alternatively you can concatenate as usual to avoid the curly braces requirement, so: $tdsphotos = $pages->find("tagsx.title=" . $page->title . ", limit=8, sort=-created");

Thanks guys - it came together quickly, but it didn't have too much fancy content to deal with. Probably the way the Who's Who section is handled behind the scenes would be a good example to show you as all people are the same in the backend, but through a variety of checkboxes and showIf's there are four people that are highlghted at the top with photos, with the President only showing at the top and not in the list further down. I love conditional fields in the dev branch already as it just made it so neat and tidy

I think you should probably take a look at the concept behind ProcessWire first, then some of the other docs and the cheatsheet as Macrura suggest - start with the Concept page from here: http://processwire.com/api/ The Cheatsheet then gives you a look at most the possible functionality at your disposal in page templates to access your data and files. As for explaining the line of code you quoted: $skyscrapers = $page->skyscrapers->find("limit=3, sort=random"); From memory, "skyscrapers" is actually a "featured skyscrapers" field, so is just a Page field that links to other pages (probably the most useful fieldtype there is. Here is the exact translation: "For the current page (homepage in this instance), find 3 random pages from the skyscrapers field". The $skyscrapers = bit is just storing the results in a PageArray (it's in the docs linked further up my post here) that can then easily be iterated through to print whatever output you desire. If you're wondering why the demo doesn't seem to pick three random pages, I think page caching must have been accidentally left on here so it's always showing the same 3 in the demo, but that's easy to switch off The syntax is based on jQuery and aims to be human-readable. If you imagine that there are a few database tables and queries behind that code, you can easily see how quick that is to write and all without a line of SQL. You can make all sorts of queries like: $architectsCalledPaul = $pages->find("template=architect, title*=Paul"); // finds all architects (pages with the template "architect" with the name Paul somewhere in the title field // and so on... The idea behind ProcessWire is that once you've learned the basics you can build pretty complicated data structures in the admin quicker than you'd be able to writing database tables from scratch and you have a hugely powerful set of functions at your fingertips to do with that data as you please. Most folks here would agree that it has shaved hours/days/weeks/months off their site build times depending on website scale, but any time saved is good!

I like movie soundtracks - thing is that when sosomething exciting is happening in the music it can be as distracting as vocals I'll try a few of the links in this topic I think and see how I get on.

It would also be awesome if we could match things like parent.template in the future as well.

Stop me if I'm wrong, but does the stockist template only apply to one page? If that is the case, you need to create a stockist.php template file which will load when you browse to that page with something like the following code: <?php foreach ($page->store_middle as $store) { echo "<h5>$store->store_name</h5>"; echo "<p class='less_padd'>$store->store_address</p>"; } However, if you have more than one page using the stockist template then something like this would work: <?php foreach ($pages->find("template=stockist") as $stockist) { foreach ($stockist->store_middle as $store) { echo "<h5>$store->store_name</h5>"; echo "<p class='less_padd'>$store->store_address</p>"; } } What I have noticed is that you mentioned _left and _middle in your code, so that might be causing an issue too. You also hadn't closed your opening <p> tag which might be hiding some content perhaps? Hope that helps.

I've added this issue to the list on Github: https://github.com/ryancramerdesign/ProcessWire/issues/288

Great stuff - I can see a few places in several sites of mine that would benefit from these to keep the code a bit cleaner!

I think that's the key - ryan's posted his interpretation of it here on the forums so you have the software author's permission - I can't think of a scenario where a court would argue against the software author's intentions partly because the GPL can be interpreted several ways as we've seen. I agree that something on the main website would be a good idea as well spelling out ryan's intentions - either on the plugin modules page or maybe a separate commercial modules sub-page that perhaps also links to commercial modules in the directory (if there's a way of filtering those? Not sure why you'd want to now I'm saying it though as it's better to search for something you need rather than filter by paid/free ).

I think ryan and my reply in the post you link cover it really. You're not altering the core, you're building something that merely talks to it so you shouldn't be worried. When ryan himself has said what you can and can't do then I would take that as permission to go ahead with commercial modules. Your specific worry about it extending the class - I get that, but that's the only way to create a module that accesses the API. In this case I think it's fair usage.