Pete

Hmm... well if they share most of the code then this might be a candidate for a module that contains the core functionality for CRUD and PW pages, then an add-on module for external DBs? You wouldn't want to be duplicating too much code - have a look at dependencies if you've not read up on that already: http://processwire.com/talk/topic/778-module-dependencies/ - then you can fire up the main module from the external table version. You might just find though that it is easier to make it as one module (I suspect this might be the case actually given the chance of code duplication).

Good to hear

Very good point - I hadn't thought of it that way. Though a lot of that remaining percentage will be different languages - ASP etc, or even just plain HTML, but yes it does prove that it's not the "main" tool. I still would like to say "19% of what?" though. Is there an explanation somewhere as to how that figure was reached? As far as I know there is no definitive list of all the websites there are on the web, so as mentioned earlier it has most likely been taken from a measureable set of data somewhere so it would be interesting to see what that dataset is.

There is already a log module for Processwire in the directory that will help - can't remember the name at the moment (on my mobile) but it logs admin actions or page alterations or something. It created a LOT of logs in conjunction with this module - dozens of pages where it published and unpublished pages. I hope I still have the logs, if not I'll reinstall both modules and let you know as I've been having this issue too.

I don't think anyone has suggested it's not easy to learn. I think the experiences in this topic (mine anyway) come from trying to make it or a module do slightly more than they are designed to. So much can be done in PW without modules in a short space of time once you get going, whereas everything extra seems to require a module in WP, and good luck tweaking them to your needs if they don't do what you want. That's just my experience mind, and I'll admit I've never spent a huge amount of time trying to get to grips with WP purely because it didn't ever seem to fit my needs well enough.

Love it I was about to say that it wouldn't work for my idea in the other thread where I was talking about using something like this for repeater fields, but then I just saw the cell types on offer here and my jaw hit the flaw: http://handsontable.com/demo/renderers.html What impresses me with the cell types is that the config data for select fields, checkboxes, datepickers and autocompletes etc can be read straight from your field's config data in PW so there is almost certainly a way of making that happen if I ever find the time. So many possibilities here, and I love what you've done so far!

It'll certainly be interesting to se if they can pass the "tipping point" - I guess that would be something like making the "big 3" into the "big 4"? There certainly does seem to have been a reconsideration of sorts and they're back to MODx Cloud from SiphonLabs again: http://modx.com/blog/2013/07/25/welcome-back-modx-cloud/ There does seem to be a bit of a push to get MODx rolled out with web hosts' hosting packages so will be interesting to see how that goes.

Nowadays I care about not working with clients who don't trust my judgement with the tools I use. The last time I did any Wordpress development it was so painful to get something that should have worked working (yet another case of trying to make a plugin go that little bit further where PW wouldn't have needed a plugin/module) that it took almost 2 days to accomplish something that should have taken 2 hours. @pwired - yes, I would definitely say - if asked by a client - it is far simpler to pick up ProcessWire than any other CMS from a developer point of view. I've been asked it before. There are all the other pros and cons though - how many ProcessWire security updates have there been? I don't think I even need to have fingers to count them Other systems on the other hand... many patches and all too often for my liking. I think it's a case of weighing it all up. Of course, if you need the work and can't turn it down then don't, but if you think you can pass a job up and wait a bit longer for one you can do in ProcessWire we all know that a lot of the time you'll complete that PW site in a fraction of the time and be able to move onto the next job quicker. I used to work for a web dev company. Usually they have small teams and welcome the input, so back when I used MODx it didn't take a lot of convincing to have new websites build using MODx. If you're working for a decent web dev company, they will be interested in your experience and interested in looking at what tools you recommend - it's not just the single (as in team, not dating ) devs who are always looking for better tools. This will be the case for the majority of clients. Larger clients will be more likely to ask, but they will also more likely be interested in whatever is the best tool to get the job done most efficiently. I think for clients who are interested, you have to seel the CMS/CMF as the tool that is best for the job, the one that is going to get it done quickest, and the one that won't tie them down in terms of features if they suddenly decide they want to add some new, complicated part to the site at the drop of a hat in the future. PW is good in terms of the unknown future requests purely because, in my experience, it's not a case of if you can do it in PW, but rather how you're going to do it - the question of "if" doesn't exist for many scenarios I've come across @Macrura - yep, if you're happy with it then that's fine. Like I say, for some sites I've worked on it's time, money and the fact that it still works the way it is. @Zahari - I like the "live long and prosper" philosophy. I don't think anyone here has come straight to ProcessWire without having used any other CMS, and without the others there would be a stifling of creativity I think. You can't have just one CMS - it's the reason there have been massive improvements in the discussion forum scene in recent years: competition breeds creativity.

Yep. I've run into a few scenarios where it's a bit distracting having the field and row headers repeat with every repeater item, plus when using it for tabular data it would be nice to use a datatable to more easily read down a column. I guess really it's a request for a completely different module, but posted here since Soma seems to be a chunk of the way there by already having experience with these things

@OrganizedFellow - it's a bit long to fit on a t-shirt, but I like that whole post @Macrura - Are you tempted - time-permitting - to change it to PW since they're asking you to do all the updates anyway? I know from a personal perspective it's just time that prevents me from going back and changing some other websites in my portfolio. Well... that and money since there's not usually money to be made in changing the system running a site if the client isn't particularly interested in changing that.

It just occurred to me that it would be amazing to be able to use a datatable for repeaters. I know it's certainly by no means a simple request, but it would definitely be neat and in some cases preferable when handling lots of repeaters or working with certain data types. Just a thought.

That's pretty much how I approach new projects now I have ProcessWire as my development tool I also wonder as to how one can accurately work out a percentage of any tool's use on the web? Is there any way of working this out for every website everywhere in the world, or are the statistics coming from a small subset, like those that show up in Alexa rankings? It's an impressive statistic if it's even remotely accurate, but it's not going to lure me in by any means

Still on target for my more than 30,000 posts a year prediction. Would be ace to get to 100,000 by the end of the year, but that might be a bit of a stretch! It sure is getting busy in here though, which is of course only a good thing

This little module allows you to store a month and day value in a single field. I originally needed it to specify how long a service runs for on a website - the type of service that runs from the same day and month every year (so datepicker wouldn't be useful there). It was more of a test to see how easy it is to build my own fieldtype - following ryan's map marker module and Soma's rangeslider module really helped and I have a few really good ideas for fieldtypes now It's not a particularly useful module as the same can be achieved with individual fields in a fieldset (well, with Month names stored as pages - something I didn't want to do) but I expanded on it a bit and made it multilingual-friendly with month names etc. On the admin side, you select a month and day from the two drop-downs, and on the front-end you can call them indovidually as numbers like this: echo $fieldname->day; echo $fieldname->month; or formatted as per the option under the field's "details" tab like this: echo $fieldname->formatted; which will display something like "April 20" which is USA-friendly (I think), but you can change the default formatting as per details here: http://php.net/strftime All in all, but of a niche field that probably won't get used much as you could even achieve the same with a text field and type it in, but I wanted the actual numerical day and month to perform date range calculations against a calendar so it needed to be more foolproof. FieldtypeDayMonth.zip

I can actually confirm it's SchedulePages that's causing at least the unpublish issue - I meant to post about that a few weeks back as one site's news that used that module had all the news unpublish itself at random - every time I'd re-publish it it would un-publish within 24 hours. I ended up uninstalling the module and everything was back to normal.

Updated code to v1.0.3 - this is an upgrade to the core Minify package (not my module or ProcessWire's code) to address a serious security issue. This update is SERIOUSLY recomended for anyone using this module! Thanks arjen for the heads-up! EDIT: Also worth noting that it was the main developer behind this forum software who noticed the flaw and suggested a fix to the Minify developers - I've also updated the Minify code in these forums. If you use Minify as a standalone package (ie. not this module, but the code available from the above link) elsewhere it would be worthwhile updating it wherever you have installed it. The issue is likely to be present in other JS/CSS minify modules/plugins in other CMS' that use the code from the above link too - I've spotted at least two WordPress modules for example that use the same codebase and there may well be others, so please bear that in mind if you use other systems.

Hi SiNNuT What happened to the Git repo for your countries list?

I do - if you pick some from lower down the list the updated date is yesterday or the 18th, rather than the actual date the module was last updated. Something to do with ryan's recent tweaks to the modules page maybe? This may be showing in ModulesManager too I guess, but I just looked at the modules page on this website.

Are you calculating volumes for shipping by any chance? Just one of the options that jumps out for me

Not a large database compared to what you're looking at, but I completed this personal project early last year which was a lot of fun with ProcessWire: http://www.strategycore.co.uk I assume your project would be this one: http://www.gamobot.com/ ? I don't see any issues with the size of your database, but there are little tricks with ratings like even if you have an individual table row for each time someone rates a game (so they can't rate it more than once) then be sure to cache the average rating against the game itself so you're not adding up thousands of rows for that simple number. All general scalability suggestions you've probably already addressed in the current iteration

I think I might have manually added the karma points (can't really remember) but not sure how widely used the karma system was - certainly there is a lot more love nowadays with the likes system working overtime to keep up with the increase in posts

Exactly what diogo said. So if your thumbnail image field is called "thumbnail" then replace the img src with $child->thumbnail->url (or if it hasn't been specifically set to only allow one image to be uploaded to that field it might be $child->thumbnail->first()->url if the field is set to allow multiple images).

Thanks - that worked

I'm getting this error after replacing the wire directory on WAMP localhost to upgrade a test install: Any ideas? I've definitely got PDO enabled - PHP version is 5.3.13

I think this is a very good point - the thing is, different sections of your site will use different fields, so why would you want to pull in every field for pages that don't need them? You have to bear in mind that it's perfectly acceptable to have a template with just a Title field in ProcessWire (there are many practical uses) so why call in a body, summary or image field if there isn't any body, summary or image content? The whole system is designed to only access the data necessary for the page you're viewing. It's also worth noting that if you are using it for a site with hundreds of thousands of pages, there are a few caching options like MarkupCache or ProCache - the latter of which will make your site lightning fast as essentially it serves a static version of a page and bypasses PHP and mySQL completely Of course there are situations where you might have to think about the best caching methods for your particular project, but if you ask around on the forums people will point you in the right direction.