Pete

This one is pretty fun and gives some ideas on how to make things fun and interesting (just the first 5 mins, once he gets started): https://www.livecoding.tv/video/live-with-stephen-wolfram/ Could have a PW one where you get ideas from the audience before starting and run through a bunch of common scenarios that way

CKEditor is already in the core of ProcessWire nowadays so you don't need to install it again. Simply delete the /site/modules/InputfieldCKEditor/ folder and it will go away. Several versions ago, TinyMCE was the default, so that's why the module exists, but isn't needed on newer installations.

Is it a PW page and you're typing code into a textarea in the admin and saving it or something like that? If it is then it will likely be some mod_security settings on your server that don't allow things that look like code to be sent via forms. Sometimes even individual words can trigger that - "Select", "Drop" etc - since to mod_sec they look like someone trying to do some damage.

Fixed the typo, thanks. The issue with uploading images is proving more difficult - I will have to come back to it tomorrow.

Hi folks There is an issue with the profile form not saving locations at the moment, and I'm not sure it's saving photos either for some reason. I will do some testing tomorrow and then notify those of you who are affected by this by the end of the week, but it seems to be profiles submitted in the last couple of weeks.

@diogo - I've had this suspicion for a while that someone at Google likes us - ever since I realised posts on this forum are indexed on Google within minutes, which doesn't usually happen on such a relatively small forum (at least to my knowledge). Now this has happened - this doesn't seem to crop up for some of the "major" systems out there so... thanks Google! (Or if it's just that Ryan has been applying the correct schema's in the HTML then thanks Ryan).

The cynic in me says it was just about getting publicity, customers and not about the actual cause at all, but maybe I'm just too negative nowadays.

Yeah, I moved house a few months back and haven't cranked my desk up to standing height once yet - very lazy. That must change today!

So what you're saying is we're already ahead of the game? I like it To paraphrase Terminator 2:

I've never really used Lister beyond its implementation on the Users page in the admin to be honest. But then there's always one who'll have the opposite view

What a client might pay him to do could be quite bespoke though, more so than a drafts module, so you wouldn't want really niche stuff going into the core anyway. Plus client work doesn't necessarily result in new modules or core changes at all as they would theoretically usually just be normal sites using existing modules, but still pay the bills. Pro modules seem to slot somewhere in between client work and core. Core is something that a lot/most people would use reasonably regularly, Pro modules are useful in certain scenarios and usually of interest to a lot less people. I think ProcessWire does definitely need some further structure in future in terms of marketing folks etc, but I'm not sure how that sort of thing even gets off the ground in other projects. All suggestions welcome, but probably in another topic.

Good spot on that first link WillyC - didn't realise this had already come up so recently.

What the guys said above - I hadn't thought about it like that and was going to suggest something else, but the more I think about my own requirements draft pages would only have been used in less than 10% of projects I think, and even then they would warrant the price tag so not an issue really and it shouldn't be core. The only draft I need most of the time is as I'm writing something before it's published, so the unpublished state does that for me. This does come up from time to time with new pro modules (pretty sure I remember a similar conversation way back when FormBuilder or something was released) but there's usually a good answer like the guys have made above. I prefer that everyone who has paid for Pro Modules gets the benefit of everyone else's questions and answers in the relevant support forums. If the modules were free to all, other community members would undoubtedly help out non-paying folks in the forums which is fine, but given that there are a lot of people here generous with their time and knowledge, folks might not need paid support or see the need to buy that option so it would be a bit of a gamble. Having said that, some aspects would be nice in core, but not to the extent as in this module. But someone could easily build a more basic module for drafts - how do you think the Dev Directory works when you post updated content? (It actually clones the current entry, you edit the clone, then when approved it's copied over the original - a very rudimentary draft system built in a short time using just a few API commands in a small module).

Cool - let us know how you get on with the front-end as I'm always interested to hear about large data projects. For topic lists on the front-end, pagination is obviously your friend, but also so is autojoining some oft-used fields in your post template - things like topic starter, topic start date, last reply date, last reply user, avatar (just guessing at fields here). Basically for the most common fields that are always going to be required whichever way you're viewing a topic (full topic or in a list or search results etc) if you autojoin them it saves on queries. This page explains it better (no idea why I've not bookmarked this one myselef yet ): https://processwire.com/talk/topic/26-what-is-the-autojoin-feature-in-the-fields-editor-and-how-do-i-use-it/

If you get stuck, feel free to share some of the code and I'm sure we can help.

Indeed. It wasn't many pages it applied to (maybe 70) but there are about 10-15 float fields in the template that need changing so yep - best to double-check these things before destroying a client's data!

Thanks man. I was thinking it was more difficult than that for some reason!

I'm going to skip the question "why" and leave that for someone else as I'm guessing there's a good reason for using Wordpress for the blog portion or you wouldn't be doing it this way The way you could do this, without having to try and bootstrap ProcessWire with every Wordpress page load, is to use a caching method as you said. MarkupCache should be able to handle this I think: https://processwire.com/talk/topic/7-new-markupcache-module/ You would have to store all the header data in a varialble and save it to the cache (as per the examples in that topic), but it would have been parsed correctly by ProcessWire and would be standard HTML in the cache and therefore ready to use elsewhere. Same again for the footer. Then you should (theoretically) be able to just include those cache files into your Wordpress template files and hey presto! It would be worth testing with a small bit of text in a MarkupCache cache file and seeing if that works.

It definitely would help - thanks. I could do with being able to do this tomorrow though so if there is an idiot's guide set of manual instructions on how to change the table data in the meantime that would be fantastic. If that's a bit too tight a timeframe then no problem The way you're proposing is interesting (to solve my "in bulk" requirement), however I'm not sure how many other people might need to do this in bulk. It might be easier (not sure) to do it the way other fieldtypes do on a per-field basis. Fr instance you can change an integer field to a float or text by editing the field, though I've never looked at the underlying code and how it handles any changes to the table in the DB. That might be the more "ProcessWire" way to go, but I'm not saying I would complain about a mass-field-converter either Disclaimer: If changing the fields via SQL turns out to be so easy that I should have known better and done it by now, I'll chalk that up to a tiring week.

What I would love is a way to change a large number of float fields to use this decimal field without recreating them (they have data in in a lot of cases and as we're dealing with money things seem to go a bit wrong with a float field but seem to work perfect with this decimal field). Is there a sensible query I can run to change the table structure? I can change the fieldtype used easily enough in the DB but am a bit wary about changing the table structure for fear of losing the data.

This is exactly what I do on one site - different browser open and load the page as a guest. It helps to do this anyway I think as there can be times where things may display fine for logged-in users but not for guests (usually when I put some sill code in and it breaks something ).

Hmm... that's a lot of big changes. I wonder why they didn't opt to call that the 2.x branch and then they could make all the changes they like and let the community continue contributing to the 1.x branch as long as they like? Seems to be a lot of things to take into consideration when upgrading, and more breaking changes to follow in 1.26. But I'm happy they're making some changes anyway.

But you never mentioned "parents" before now

I think this is your limiting factor here. I have built something similar as part of a wider, integrated intranet system however if your time is short you can't beat using some pre-existing software. Nothing will beat ProcessWire if you are likely to want to introduce functionality not available in some other system as ProcessWire is one of the few platforms where you can change your mind about something or come up with crazy new ideas and it not be a problem to make larger changes, but if you're likely to only need a normal WIKI type system then you probably won't replicate all the functionality you want in just a few weeks. That said, I hate that MediaWiki seems to be the main option out there (there are others, but they all come with their own maintenance issues too) as it's a bloated piece of software (so slow and resource hungry for what it does) on an out of date codebase in my opinion. I would love to have the time and money to develop something in PW as coupled with ProCache you'd be onto a winner and have something infinitely more customisable if a lot simpler, but it would be a project that would take several months at least I would think to cover everything (well, the basics) of what something like MediaWiki can do. Not sure where my train of thought is going, but I guess if you're really tight on time, you should probably invest that in installing, skinning and getting to grips with something that already exists. If the project is longer-term overall (as in you'll be looking after this system for years), then this buys you time to develop something as a version 2 and does you a favour in a way as you'll know what the client does and doesn't use in the system you've installed so you know where to focus your efforts in a custom-built system. Hope that's of some help anyway.

$g is an array of pages in your example that doesn't seem related to a particular page, so how does it know what next and prev are? Next and prev usually relate to the page being viewed, so $page->next() and $page->prev() should be all you need.