Get last day of last year – obvious, but still (+1 this for first day):

SELECT DATE(CURDATE()- INTERVAL DAYOFYEAR(CURDATE()) DAY);

And how useful… FROM_UNIXTIME takes a unix timestamp and makes it a friendly datetime, its like they KNOW I am coding for facebook data acquisition…Anyhow…

To make a GMT UNIX time-stamp for the first day of this month:

SELECT UNIX_TIMESTAMP(CONVERT_TZ(DATE(CURDATE()- INTERVAL DAYOFMONTH(CURDATE()) DAY), '+0:00', 'SYSTEM'));

You can switch out the dates obviously, and there are probably other ways, still, mostly pain free.

The post MySQL datetime examples – first/last day of the year – dates and unix-times first appeared on Woody Hayday | Blog.

• Dont try to SET anything, skip them. ANSI_NULLs, ANSI_PADDING
• Replace CURRENT_TIMESTAMP with (getdate()) – easy to forget this but I always seem to use it as a default.
• Keep constraints on line

Of course if you wrote your tables from scratch in T-SQL it probably wont be a problem.

The post From SQL Server 2008 r2 to SQL Compact Edition. Doing things the wrong way. first appeared on Woody Hayday | Blog.

The post Google BigQuery and Predictions API – Swap data for processing time? first appeared on Woody Hayday | Blog.

The question then comes after you have 30 wordpress blogs on the go, various niche market’s blogged too or personal sites about cats or what have you, what then? Updates then. WordPress do update fairly regularly, they aren’t the slow moving behemoths some other companies are because they are open source, and that’s a good thing. Anyway maintaining 30 copies of wordpress is actually a lot easier than it sounds, an update is usually nothing more than 10 minutes uploading the new wordpress files over the old ones via FTP. But say you had a little project where you wanted to create a few more wordpress blogs. For the sake of this post lets say you wanted 90 blogs. 90 WordPress blogs installed on an average web host (I suggest 1and1) is not a big deal. It can be as big a deal as you make of it but in your pursuits and interests online its potentially likely to crop up.

You can run 90 wordpress blogs (or 1000 etc.) from 1 instance of wordpress. That is 1 wordpress folder on your host serving to 90 blogs at blogsite1.co.uk, blogsite2.com etc. thats nothing new – I am sure the quicker off the mark or longer in the tooth of wordpress users have been doing it for a while, but somehow I missed this up until I got past the 30 blog mark and so I thought its about time I looked at the option of hundreds of wordpress-blogs running from 1 folder, a project has come up. The reason this works by the way is the wonderful way (take not web developers) that wordpress splits its config files and its database. The only file in the wordpress files you upload to your blog that contains any site specific data is the config file, which pulls everything from the database.

On the preface there are both good and bad things about doing this with word press, here are the pro’s and con’s as I see them pre-project.

Pros

• Single central wordpress folder  – 1 wordpress folder to update periodically
• File size – rather than using up 4mb per wordpress install, this method uses 4mb per x number of wordpress installs, although space isn’t an issue really in current web hosting
• Plugins and themes only need to be copied once – they can effectively be shared
• Easier to backup – backing up files of wordpress blogs is pretty pointless apart from wp-content (uploaded images, themes, etc) – putting all your blogs in one basket means backing up the whole lot is a breeze, 1 folder not 90!
• WordPress database is seperate – you could potentially run all the blogs from 1 database too – (capacity dependant) – as wordpress allows table prefix’s
• Adding a blog can be automated – replicating the first wp database from an install can mean tons less setup work

Cons

• Permalink structure may have to be the same? *not 100% on this one and havent tested but there may be issues with permalink setups across multiple blogs as htaccess is shared*
• Other .htaccess differences – because you will effectively only have 1 .htaccess file for all domains pointing to this folder, this puts all that custom .htaccess code out of the window
• Flip side of themes being easy to install is that editing one theme will lead to all blogs using that theme to notice the change, fine if your blogs are stable in design but multiple versions of the same theme will be required if you want to tweak these on a blog specific level, which could make for a messy confusing setup if not through through
• If you are running a network of blogs and want to stay under the radar or just want the sites to be as different as possible – by nature of single resource they will leave footprints unless you are aware and make sure you do things like rename folders for themes non-sequentially etc ( or maybe don’t be paranoid :p )
• Centralising the files for all domains/sites/blogs does mean this folder on this box does then become a single point of failure, loose/break this and the whole of your blog network/project is down. Probably not such an issue with stable hosts these days
• As previous point if you do update, change a file or accidentally delete anything it does effect every site – its a risk but not a big one just be careful!

Limitations

• Unsure about .htaccess but presume custom rewriting becomes a pain as all sites share a file
• There will be a limit as to how many blogs you can run off a single install. It’s probably thousands though – if you had 30,000 sites for example – the file which points the install to the right database tables would become bloated

How to run tens, hundreds or thousands of wordpress blogs from 1 instance – install wordpress once for hundreds of blogs – without MU.

1. Install wordpress into a folder on you hosting (download latest from wordpress.org and then upload via FTP/copy across network)
2. Get your database details together, you will need Database Name, Database Username, Database Password and the Database host for each of the databases you are going to host wordpress tables in
3. Install a single blog using the normal method – point a domain at the folder, go to that domain and follow the wordpress wizard, entering your database connection details and this blogs title.
   1. Go through this newly installed blog and commit any changes that you will want duplicated throughout the new installs – delete the “hello world” post/default wp links for example.
   2. Imagine this like creating a ghost image for a network of pc’s – you want to make a bare bones default wordpress setup so you can replicate this onwards without having to redo it.
4. Happy with  your ghost blog setup? go to your phpmyadmin (assuming you have it) and export all the tables for this blog into SQL.
5. Open that SQL into your favourite text editor, in this case I am using Dreamweaver because I like its find+replace.
6. You will need to do several find + replaces here, but by doing this you can literally clone a wordpress installation – (works as at 2.9.1 anyway) – this is great for mass distribution (This is quicker than installing and can be automated)
7. For example if your site was “harrysblog1.co.uk” with a title of  “Harrys Blog 1” then do a find and replace for “harrysblog1.co.uk”, switching out the new domain to be added, same with title’s, users, post’s etc. This way you could clone a wordpress site and switch out words…you can change the table prefix this way too.
8. Run this newly modified SQL on whatever mysql database you want to run the blog from (could be same one if you mass replaced the table prefix’s)
9. Alter your wp-config.php file very simply:
   1. Open it up and put a bit of logic which basically says “what domain am I loading from, ah this one – use this DB and this table prefix” – This logic can be as simple or as complex as you want it to be – I kept mine short and sweet with literally:

*note this is just how I did it, there are other ways – the code works but was just to test the theory – when upscaled to a network of xxx or x,xxx sites this is automated quite easily

*note2 I am having to cut this post short but if anyone has any questions or wants to know more/help on replicating wordpress or multi blog – 1 wordpress instance installs let me know in the comments

References

Striderweb – this post pretty much explains the theory, a bit like this post – but I actually happened across it after writing the post – well worth reading if your going to do this – Stephen Rider has made a great plugin that will do everything you want it to do as above, I winged it and just modified the wp-config which simply worked in my case so personally I didn’t use it, but no doubt its probably worth a try if  you want a more deep solution.

The post Multiple WordPress blogs from 1 instance / 1 wordpress folder to maintain first appeared on Woody Hayday | Blog.

The post ReSeed Identity column – TSQL first appeared on Woody Hayday | Blog.

Here is how I managed it:

–make procedure to cycle trhough entrants and assign them to a room
create procedure [dbo].[files_2_check] as
DECLARE @fileAt varchar(2000)
DECLARE @fileEx int

DECLARE checkCursor CURSOR FOR
–select top 10 FileDirectory + FileName from files – USE to test it first
select FileDirectory + FileName fromfiles

OPEN checkCursor

FETCH NEXT FROM checkCursor
INTO @fileAt

WHILE @@FETCH_STATUS = 0
BEGIN

set @fileAt = ‘\\192.168.1.8\f$\Files\’ + @fileAt
–this will depend on your network address

print ‘Searching for ‘+@fileAt
EXEC master..xp_fileexist @fileAt, @fileEx OUTPUT;

if @fileEx = 0
begin
insert into dbo.tbl_fileCheck (fileLoc) Values (@fileAt)
–doesnt check for already existing, archives by date though
print ‘…NOT FOUND – Recorded to DB’
end
if @fileEx = 1
begin
print ‘…OK’
end

set @fileEx = 0
set @fileAt = ”
FETCH NEXT FROM checkCursor
INTO @fileAt
END

CLOSE checkCursor
DEALLOCATE checkCursor

Which basically grabs the rows containing the file directory/filename and uses a cursor to cycle through each one checking them using the xp_fileexist command. There were a number of ways available to do the actual file exist checking but this one suited best, This solution definately works on SQL2005 and forwards, although did need a few additionals:

Turn on the setting (potential security issues if this is on 24/7, but you could run it on a vanila ms sql db server elsewhere) – Worth turning off afterwards.

exec sp_configure ‘show advanced options’, 1

go

reconfigure

go

exec sp_configure ‘xp_cmdshell’, 1

go

reconfigure

go

Apply admin rights to the MS SQL Windows service – by default this will only have local scope, it needs you to go to the services properties, then logon tab and assign it a user which has scope to view the files its checking exist over the network.

The post xp_fileexist Network Drive – T SQL Based File checking first appeared on Woody Hayday | Blog.