Pete

Soma, before I read your reply HTML Kickstart came to mind so your use of the word "kickstarter" amuses me as we were thinking along similar lines I think it would actually be better if we had a few profiles as really basic templates and picked a few main frameworks. So as an example off the top of my head, one of us builds the gallery profile in the PW admin, then chooses HTML Kickstart and does the front-end templating. Someone else (or the same person) then re-does the front-end template in Skeleton, then in Twitter Bootstrap and I think that that would actually create some very simple starting points in 3 mainstream frameworks for people to run with. Again, this is possibly more useful for devs but at least with two of those frameworks (Twitter Bootstrap and HTML Kickstart - Skeleton would take a bit more work as it's more streamlined), but it would also give less technical users a good starting point too. What do you reckon to that?

Hehe, shows how much I know - it's already set up that way then

+1 for Joss' note about server power. Any system where you are getting into hundreds of thousands of entries that will be searchable will put a bit of strain on the server, but as long as the server is powerful enough it's not a problem. Assuming all this is text and it eventually gets imported into ProcessWire, it'll be in the database so won't be taking up physical disk space any more. The tricky bit is an import script to handle 24,000 files per year. To be honest I would suggest you might want to consider working with someone here on this to help set that up for you as it's not a trivial task. That does bring you into the realm of paid work though but thought it was worth mentioning as you're going ton need a converter that is clever enough not to time out, that won't break due to anything unforeseen (random characters in the title of one article could trip it up) and so on. Basically someone who could do the conversion work and be on hand if anything goes wrong. Just a suggestion, but it does sound a bit less straightforward

I've encountered it once in 10 years and dozens of clients. I moved the site to a new server after days wasted trying to resolve issues that don't exist with other hosting. This was names.co.uk as well some years ago.

Looks like the version of PHP would be the main thing. I would be wary of any host who is not in a hurry to upgrade from what is now a quite old version of PHP to be honest. Also Zeus means .htaccess won't work and you need a whole different set of rules from memory as it's quite different in that regard.

In case anyone was wondering: http://www.bbc.co.uk/news/world-us-canada-21001452 And I learned something I didn't know - he co-authored an early version of the RSS spec when he was 14.

Ah, well I wouldn't mind something like that being included in the core distribution to make it possible for any module to call AJAX from itself if that's what you mean? If it was core it would probably also be more secure than some of the stuff I write

@Joss - I still use Dreamweaver (I'm on Creative Cloud, so it's the latest edition) to edit code and there's no reason not to use something else, it's just that for localhost the file tree is useful to me @Antti & Matthew - exactly. Perhaps what we need to push on the site is the fact that you can implement any theme you like - one you'vebuilt, one you've bought or one you got from a dodgy guy down the pub. That would certainly compliment and expand upon the message of ProcessWire not making any assumptions about markup, and to the less techy folks actually capping it off clearly with something like this would probably help: "ProcessWire doesn't make any assumptions about your markup. This means that you can start from scratch and build your own theme or implement any theme you like from a template site". Something like that but written with more thought by Joss

Here are some take-with-a-pinch-of-salt stats. Topics and posts is self-explanatory - nice growth with both Views isn't over time - it's the most viewed topics as recorded by this forum software (bear in mind that some forums are newer than others and that we only converted to this forum software about a year ago, so Google Analytics could probably give better figures, but this shows some interesting reading habits too). Adam, this worked for me in Firefox - can you try a different browser?

Yep, normally I would also stick something in a folder called /site/tools or something like that. The problem I'm facing is that I'm trying to do this with an installable module and keep it tidy, but you cant run scripts from the module directory. I'm open to suggestions but those are the limitations I'm working with.

Because it took me longer than an hour to write it In my defence I did have other tabs open with other things going on too.

I've just set the forums to disallow you doing anything Adam No, but seriously, how are you trying to include the image and what steps do I need to do to reproduce it? Joss - you're right, but I was gone for a while in December and now I'm banging out about 10-20 posts a day I reckon so it's probably all my noise

You don't need either to be honest - you can just use the default profile. The idea with ProcessWire is that you then build your templates in teh admin with whatever fields you need and go from there. Everything is customisable - for an example of this, try this: http://wiki.processwire.com/index.php/Small_Project_Walkthrough or watch ryan's intro video on the Videos page: http://processwire.com/videos/

Ah, I will have a look at it tomorrow again

That Twitter link is a pretty common occurrence. Things like that happen on the web every day as I'm sure everyone knows - I've seen things like "X looks like Y, must be a rip-off" due to things like colour schemes over the years and I don't think the users get confused over minor similarities (if you're logged out of the forum software here, the skin for that has green, square buttons at the top-right, and that's in the forum software's skin, nothing to do with EE or PW so nobody has the rights to a colour or shape in my mind ). Obviously it can go too far with whole interfaces copied, hence my earlier concern - I've had an entire one of my sites cloned in the past and that was annoying to say the least. On to the rest, there's some interesting stuff there - a lot of your questions can only be answered by ryan I think, but here are my personal thoughts on some other parts: It took me a while to understand what you meant by Blocks - I thought this was something to do with EE to begin with, but a search on Google shows it's a new CMS. The title is very clever - whilst it sends shivers down my spine ("blocks" to my mind brings back visions of the web when data was very much siloed into containers and is the realm of older CMS' in my mind, though I know a lot are still around that operate this way) it's also very clever, as that's a term most non-devs are familiar and comfortable with. I'm not suggesting that's how it works, just that it has a clever, simple, catchy title Hope Apeisa doesn't mind me giving my thoughts on the the ProcessWire e-commerce module and I hope I'm not miles off with this (correct me if I'm wrong Antti), but it is marked in the modules directory as being at proof of concept stage at present. I think I'm right in saying that it's in use on a couple of sites though so it does work. Apeisa, is part of a larger dev team in the company he works for (again, correct me if I'm wrong) and the module was built to fulfil the needs of a website for one of their clients. At some point personally think it will have developers building payment and shipping modules for it and it being one of the key modules, but I think it's fair to say that it is in the early stages at the moment. But it's one of the oddities of ProcessWire that you could technically whip up a payment module in an hour or two that will work with it and be using it quite happily - there's just lots of features that dedicated e-commerce solutions have that aren't there yet because nobody's picked it up and built those extra bits into it as they haven't had the need to yet. I know personally though of one ecommerce site I've built recently where I wished I'd built it in ProcessWire and expanded upon that module rather than pour as many hours as I have done into a full-blown e-commerce solution trying to bend it to my seemingly straightforward needs There is the potential issue at present (and I think I'm getting a sense of that from your post) that it's not apparent who is behind ProcessWire. I think (personal opinion again) that this is intentional as it's ryan in the driving seat with the rest of us contributing with support and tutorials on the forums, docs on the Wiki and of course the modules. There are also rare cases someone will write some code that makes it into the core, but the rarity there is no bad thing - it's just that ryan's built the system so well and it's already incredibly powerful. If you really get stuck in with it and experience the power, it all seems so elegant and well thought out, and at the same time there's so much in there that if I didn't know better I would expect it to be the work of a larger team rather than one person. I've honestly never seen anything this complicated work with so few issues or bugs - ryan has a rare gift (and a tonne of experience). I think it's fair to say that it's a community effort as a whole, and if you spend some time on the forums you can kind of get a sense of who does what (I talk lots and use brackets far too much in every post) but maybe one of the next steps is to loosely define a "team" with "roles and responsibilities" - the thing there though is that you're stuck between trying to do that to be helpful to newcomers to show who does what, and at the same sounding a bit like a big company-driven CMS and introducing hierarchies where those in the hierarchy aren't actually coherently linked to a company. It puts people's minds at ease, but it can be a bit smoke-and-mirrors. To me, the "next level" isn't about churning out modules, even if they are quality - that will come with time and I expect we'll be well into the hundreds in 12 months' time, but why have what others have? As a bad example, Wordpress has 125 pages of plugins just to do with the word "gallery" - that's over 1,000 gallery-related plugins - how many ways of delivering an image gallery are there?! Also consider that a normal gallery wouldn't even need a module in ProcessWire, just a template, a few lines of code and you're away - it's already there in the API functionality-wise. I hope that as we see more modules written for ProcessWire that when it looks like someone is re-inventing the wheel that we can persuade people to work together and have a modules combining different options where appropriate rather than lots of modules doing almost the same thing, but I think it's inevitable that we'll get to a point somewhere along our upward curve where that's too much to manage. The beauty of ProcessWire is that the basic requirements for the majority of small and large websites are already covered out of the box. It's just things like ecommerce that need some more attention at some point. (Another irrelevant personal view - for most developers I'd wager that unless you're specifically targetting shop owners the majority of your sites aren't shops anyway, but I can see how it would be off-putting if your business revolves around e-commerce - still, there are tools out there for that so there's no rush to have a full-featured solution for it in PW). The "next level" things to me are more about: Official docs on the website - something more coherent that gathers together the Wiki, the main Tutorials etc and has use cases (with code) for every function in the Cheatsheet Probably a structured series of screencasts to highlight some of the common things you can do - focusing on specific things like image galleries etc. They're almost the same thing, but it's important to cater for people that prefer to learn by reading and people that prefer to watch tutorials being built before their eyes. The more we show people what they can do if they get stuck in, the better, but ProcessWire's key differentiators are that it makes no assumptions about your markup or the type of site you want to build - therefore it makes you get your hands dirty with a little PHP, HTML and CSS. This will turn away a lot of people I'm sure, but I'd say that if you're not willing to roll up your sleeves and get your hands dirty just a little then why are you building a website instead of hiring someone to do it for you EDIT: Adam beat me to it by almost an hour, but his answer is a concise version of my waffle

Forgot to mention, I've pulled in the last of Soma's pull requests so this is now v1.0.5 to implement the added functionality he wrote as well as the fixes for the bugs he created My fault for not testing

Exactly what Joss said, and here's some pointers as to how easy it is to hook into ProcessWire to create a page (the last step of your conversion script) programatically as opposed to doing it by hand: http://processwire.com/talk/topic/352-creating-pages-via-api/

Something that the forum software does is that it only limits it to seconds, minutes and hours ago, then in other places says "Today at X:XXam" and finally "Yesterday at X:XXam" so it would be nice to have those options and set a cut-off in a future version so that "if the date is before yesterday then just return the date formatted with date()" for example The thing is, once you get past today and yesterday, you have to think about your use case and whether "11 months ago" is actually that descriptive. Not a criticism, just a note that when using this module you have to think about where you're going to use this and how accurate you want to be.

I like this as I spend a lot of time on forums and these little things make it seem more friendly. Nice work!

Without knowing much about the code I'm going to say that it should be possible to abstract it out at some point in the future to make it easier to drop other editors in with their own links into those parts of the core but I can see why ryan would want to leave it til later. It brings up tricky questions like if it's removed from the /wire/modules/ dir, how do you get the new distribution of /site/modules/TinyMCE to people upon upgrade? Since it wouldn't be packaged with the new version it would have to be done automatically by the then-integrated ModulesManager I think, causing someone yet more fun coding headaches But yes, I'm going to go out on a limb and bring out that line I like to use: "Everything is possible in ProcessWire".

Digging up an old topic I know, but I had a need to have a module do some AJAX to request some content from itself - the details of that are irrelevant for now, but you can have a module intercept a page request so that you can have all your PHP code from the AJAX request sitting neatly in the module itself. For example, if your module's JS file sends an AJAX request on click of a certain element and you want it to return some data, you can do this in your module's JS file: $('#myelement').load('ModuleName-ajax?do=something'); And then you can intercept that request to yoursite.com/ModuleName-ajax by putting a line like this in your module's init() if (strpos($_SERVER['REQUEST_URI'], '/ModuleName-ajax') !== FALSE && isset($this->input->get->do)) { echo "Nice!"; exit; } And of course this then echo's "Nice!" into the leement with the ID "myelement" in your HTML. The only reason I used the module name followed by -ajax was to make sure that that would never be a page on the site. It just avoids confusion if you made a site about modules I wonder if someone will tell me there's a better way now

Rollback (and roll forward) is a great idea, but yes that would be more work A way to do it is have a /site/archived-modules/ folder and stick the older versions in there by module name and then by version. What are you thinking in terms of the manifest?

I meant Nico <sings badly>Oh oh, diogo, Nico, whoah, don't go</sings badly>

I honestly can't remember now... I have a feeling it used to be that if you set it to 1 then it wouldn't but there was a conversation where I think maybe ryan said in 2.3 and up it would now still work with ->first()

Yup - it's just because it can take any number of images by default, so if you change the field settings to only allow 1 image then be sure to remove ->first() from your code.