Pete

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.

Oh ryan, I need this today and here it is Your timing is impeccable as ever! Excellent work once again.

I'm also in a rush, but there is more info on this topic here: http://processwire.com/talk/topic/3567-similar-posts-by-categories-or-tags/ The "Page" method mentioned in a few of those links is the way to go really, as it allows you to add descriptions to tags, so if you have each tag as a page (not as odd as it sounds - you want to click on a tag and see a list of pages after all ) then you can add an associated image, introduction etc - whatever your imagination can come up with Basically there is no apparent tagging system because there is no "right" way to do this in ProcessWire - it's more flexible than that.

Just a quick note to those trying unsuccessfully to login via Twitter the past few weeks - this is finally fixed now and you can carry on as usual.

@fatih - I would suggest that you change all of the passwords you linked to in your last post, as anyone reading it can now mess up your hosting. Also, Google indexes these forums extremely quickly so it is likely that anyone can now access your hosting. Never post real usernames/passwords in forums - if you need to pass on such details, use the personal message feature here or encrypted email. @dups - you seem to have done the same in your first post too!

Sooo... I worked this out and it is now on the search results - might have to got to page 2 to see some though at the moment as newer posts tend not to be answered

Thanks ryan - used this at the weekend to replace a home-brewed bit of code I was using that didn't work after the Twitter API 1.1 update. The markup options were especially handy as it meant I didn't have to change my template code much at all

You had me at git clone ssh On a more serious note, excellent first post - thanks!

I'm in the process of building a complicated module and was thinking that being able to create the fields in the admin quickly, then export as a JSON string to use in the installer function would be much quicker than what I'm faced with at the moment - manually typing out the code for all the fields I need to add is taking a long time, so aside from the uses when copying fields/templates to other PW installations it would be fantastic to be able to generate the JSON and in a module's installer just do something like this if we wanted to change some template details or add some additional fields: $templatedata = json_decode($jsonstring); $fieldgroup = new Fieldgroup($templatedata->fields); $template = new Template(); $template->name = "template-name"; $template->fieldgroup = $fieldgroup; $template->save(); Or if we were happy with the template name we'd exported and all the fields, then this: // Adding template "template name" $templatedata = json_decode($jsonstring); $template = new Template($templatedata); // $templatedata contains template and field information $template->save(); The second option means you won't even know what the template is called unless you know how to read a JSON string, but I like its simplicity, and we can just put a comment above it as in my example Just a thought.

It is a difficult situation pwired. I guess all you can do is sacrifice your evenings and weekends to some extent, even though your brain may be fried by the 9-5 work. I think to get back into the half-and-half situation again you need to to the extra work whenever you can to build up the client base and enough money to go back to half-and-half. Not sure how else you would do it.

Yes, that's how you would do it. Think about it like this - each page in your web application presumably does something different, so needs a different page.

Thanks Macrura - I love the detail of the first link in your post. That chap has done an amazing job breaking it all down The second link is... interesting. They have 3 hours down for a contact form and only 12 hours for an Android/iPhone app. I think the app could take longer than the rest, but then I'm not an expert in that area. The rest I suppose depends on your CMS as a contact form should technically take under an hour. Quoterobot looks like it could be a great timesaver, but however you do your quotes, charge what you think you're worth. Somebody linked to this in another thread here, and whilst it's all useful info, there's a bit at the end where someone has thanked Mike for giving them the confidence to charge more - like Mike says, they were almost certainly charging too little: http://vimeo.com/22053820 And the last link - I only realised recently that what he says is true and applicable to anything to do with web development. Another way to look at his statistic of 9/10 clients think the price is too high is that which would you rather have? 9 clients who have a hard time parting with $350 for example, or 1 client that is happy to part with $1500? He would need 4 of the cheaper jobs to cover what he makes in 1 at the higher price. Obviously I made some of those figures up for illustrative purposes, but you get the point. Of course, that's only workable if you can get away with charging that much and are comfortable enough financially and in general that you can turn away a job and wait for the next one if it's not quite right.

I think the problems inherent with a table booking system are as follows (and this is with no real research by the way): Do restaurants have a good grasp of how long a table will be occupied for? If so, give them an option (maybe default to 2 hours per table) Different table sizes will affect the booking. You need to enter your party size ideally to see what is available. That or the restaurant may be able to push tables together in many cases - how do you deal with that? If you're using a web booking system for a restaurant and it needs to be up to date, the system needs updating whenever walk-in customers come into the restaurant. Either that or you can only book online X hour in advance (4 hours default maybe?). Basically, what I'm getting at is that there are far more variables in play than other booking systems. Booking a holiday cottage is easy - it's got a fixed number of beds - no problem. Booking a hotel room is slightly trickier - you have more options, not just with how many beds per room, but type of room. The more I think about it, the less likely every eventuality will be covered just by the module I'm creating. I think it far more likely that each scenario needs to be tailored and that they might be best as site profiles since there will be a lot of templates with them. As such, the module I'm working on may help as a starting point for accommodation/asset-based booking, but won't be much help for table bookings and other time-of-day based scenarios. At least, not in version 1.