Pete

That sounds manic, but at least it's more interesting than painting a kitchen. Fortunately I have given in for the day and can now get back to doing web stuff. Hmm... maybe that should be my motto - "I do web stuff".

It seems the ratio code from the old post isn't what's used - the text above the table itself has the new code. Not wanting to sound like a sore loser, but it doesn't make a whole lot of sense to me, though I've not touched statistics since I was in school really so maybe it does? (($likes / $posts * 100) * $likes) Since it's a table of top posters, shouldn't it just be sorted by most posts, leave the "likes" column on and remove the "relation" column?

Hehe, I was here before ryan Nah, that number 1 spot is simply the member ID, and since I converted the forums from the old software it automatically made me number 1. I'm a bit confused by a lot of that. Sorting by member ID seems to return random members and I'm really lost as to what the Relation column is all about - I've not had that many relationships (or that many relations!). EDIT: Silly me - the member column sorts by name!

No problem. Not sure what you mean by "the syntax" though? The foreach loop is normal PHP code (more control structures here: http://www.php.net/manual/en/language.control-structures.php ), so you're unlikely to find that on the site docs purely because you could be doing anything with a set of pages, not necessarily looping through them to display them so the cheatsheet doesn't make assumptions. There are quite a few examples of this type of code in the default template (head.inc has a few loops and examples of urls and titles etc being echo'd to the page). On to your additional fields for your file field - you were right with repeaters, but you will want to edit your file field and set the max number of files to be 1 (it's set to zero by default which allows unlimited files to be uploaded). If you use your files field on other templates where you do want to allow multiple uploads in that field, you might want to clone the field and call it something else so you can have one file field with just 1 upload allowed for your repeater and another field for other uses that allows unlimited files.

Hi Helmut In ProcessWire everything is custom. I would suggest watching the overview video for starters: http://processwire.com/videos/ and perhaps playing with this tutorial to get an idea of what you can do with some of the different fields: http://processwire.com/talk/topic/693-small-project-walkthrough-planets/

Welcome to ProcessWire! Assuming your file field is called "files" in the admin, you could do this in your template: <?php foreach ($page->files as $file) { echo "<a href='$file->url'>$file->name</a> }You could also substitute the name with the contents of the description field too.A pretty complete list of functionality can be found on the cheatsheet at http://cheatsheet.processwire.com

terry - your amended code would work with any array, it's not ProcessWire specific and is just a case of having a counter that increments as you iterate through an array. I would set $i = 0; before your foreach though just so it knows what $i is before you start incrementing it - with stricter error reporting turned on it would probably throw you an error otherwise. The code is puzzling though as it doesn't really relate to anything in the PageArray. Since you can sort based on date ascending or descending, by title asc and desc etc etc just having this counter doesn't seem to achieve much as $i doesn't relate to anything in the array - it's just a running count of how many items there are. Is it being used for anything in particular?

I was wondering if this could be part of the installer - an additional step to tick some additional, oft-used modules and choose an RTE? It's not making an assumption about how you're going to work that way, but some thought would need to go into the list of immediately useful modules (I generally always go with PageLinkAbstractor, Thumbnails and CKEditor nowadays before I do anything else). It wouldn't need to be an exhaustive list as there could be a sentence at the bottom saying there's more when you login. I think this goes along with another idea I had a while back about part of the install process involving asking what profile you'd like to install and it then going off and downloading that, but that depends on server capabilities - though I'm not sure I've heard of anyone having issues with the way modules can be downloaded in the admin lately?

I know it's only a Proof of Concept, but I'm 50/50 as to whether this is a good idea or not if it's auto-saving live pages, no offense intended, as it could be updating part-changed content on a live page if you're halfway through typing when it autosaves couldn't it? Some people write/edit loooooooong pages I think it would be better if it autosaved to another part of the site (under your process page for example) and if you leave the page you're editing and go back to it it could do a comparison of modified dates and ask if you want to edit the later, non-live version. Of course, that's quite a lot more code but it's just an idea (it's also leaning towards version control too in that case).

Thanks Soma - I knew it would be something easy like that - works perfectly

I've just noticed something with front-end logins - too many failed login attempts throws an ugly server error (since we're not logged in we don't see the nice too many login attempts message). Is there an easy way to intercept and display the appropriate error on the front-end instead of seeing a nasty-looking error page?

Your post has been up for less than 12 hours - if you are patient someone may help, but a lot of us were asleep for most of the time this has been up so far!

I'm thinking about Caching and areas of a site where there is just ONE dynamic element to keep things fast for everyone. For example, any site that has member accounts. What would be the possible ways of approaching this whilst still having the rest of the page cached as much as possible? I was toying with the idea of an AJAX request to load the member-related menu items after page load. The up-side is a quick load time for the page and that you could theoretically keep using ProCache whether logged in or not (if you could configure it that way) but the downside would be a delay to loading the member-related page items. In the background of course, you've just gone and initialized ProcessWire as part of the AJAX request, so there's no savings to be made in terms of load on the server there, but I sort of like the idea of loading the content as quickly as possible. Another way to do it could be with an Iframe, but that feels soooo last decade The other option would just be to use MarkupCache on all sensible places on the page to keep things simple for the server when members load the page, use ProCache for guest users and make sure there's enough grunt in the server to serve pages as quickly as possible. Any other suggestions? Or am I trying to over-optimise things do you reckon?

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!