Yup, it’s 2014 and there are countless articles written about security your PHP code. Hell, most people use a framework. Today, I took over from another developer on a rather large internal quoting system, from another company. The company, rather ironically, class themselves are “the web experts”. The following gem was written on 23/10/2014. I present the following in all it’s scary, insecure glory:
Continue reading Brace yourself, code like this this still exists
At a recent business networking event I got talking to another web developer, who has just started using Laravel 4. We got chatting about Laravel in general and how awesome it is.Of course, the subject of IoC cropped up. The other developer commented on IoC, saying, “you need to be really careful with the IoC and passing an instance of the $app into the closure for performance reasons, the $app shouldn’t really be passed through at all ideally”. His argument also focused upon the fact that injecting the “Laravel 4 Facades” (
config/app.php line 151) into controllers as it is faster.
Personally, I think he’d missed the point of IoC here. The only point he does have at a push, I assume, is if the object doesn’t need an instance of the $app, then don’t pass it through the closure – but that’s pretty obvious?
Continue reading Laravel 4 IoC – Bindings and the Application Instance
During application development sending test emails can usually be a pain, even when using a modern frmaework like the excellent Laravel 4. During development it is very desirable to debug emails without actually sending them.There are a few options I’ve come across:
- Use Laravel 4’s Mail pretend feature. Simply set the configuration key “pretend” to true in app/config/mail.php. Laravel will now not send emails, instead write the content of each email to the application log
- Manually change the “to” email to your own so emails are delivered to your favourite email client – again, messy if sending lots of emails and if you ever made a mistake
- Print out the email data directly to the screen, but don’t send the actual email – the worst solution in my opinion
Options 2 and 3 are particularly fraught with issues. For instance, assume the application was to send out 1000 member renewal reminders and during development the route that sends out the emails was hit. Very soon, we’d have some very real (and confused, annoyed etc.) customers contacting you – disaster!
Continue reading Mailcatcher & Laravel 4 – Sending Development Emails
The Opencart Multistore feature is a great addition for retailers requiring multiple stores, managed via a single administration area. Setting up multistore in Opencart is quite easy and can be accomplished in a few minutes.
However, after visiting the new store you’ll immediately see that existing products, categories, customers, page layouts etc. have not transferred over. Ouch! The new store is completely empty.
Continue reading Opencart 1.5.x Multistore – Associating Existing Data
When using the excellent Laravel 4, writing DRY and SOLID code is something you’re well aware of. Unfortunately, it’s common for the routes file to get messy and repetitive as an application grows – enter the route pattern method. Even worse (in my opinion) is performing basic and repetitive validation of parameters in controllers.
Consider a routes file that responds to 4 simple URIs:
Continue reading Route Patterns in Laravel 4
SSH, or Secure Shell is something any web developer will have come across. Personally, every single website I deploy involves SSH where I’ll upload and extract a single compressed archive. This is simply good practice and most importantly, much faster than normal FTP. There are a plethora of further benefits in having SSH access – I won’t go into these here though. However, as common a feature as SSH access is, gaining SSH Access on a Heart Internet hosting account surprisingly, turns out to be pretty darn hard to get.
Continue reading SSH Access & Heart Internet, oh my …
Database seeding can be a pain to perform and end up very clumsy. Seeding is a process required in the majority of web applications – either for stress testing or just to generate a reasonable sample of test data during testing. Laravel 4 already has database seeding and migrations built in, which of course is great. However, the functionality to generate the actual sample data is lacking. Enter Faker – a package, available via composer. The author describes this better than I can:
Faker is a PHP library that generates fake data for you. Whether you need to bootstrap your database, create good-looking XML documents, fill-in your persistence to stress test it, or anonymize data taken from a production service, Faker is for you.
Continue reading Laravel 4 Database Seeding with Faker
Counter Cache (or Counter Cache Columns) is the term coined when adding a column to data tables in order to keeps track of aggregate data in an application. The term “cache” is used because the application has no need to perform costly count queries. It can simply read the value of the “count column”. This practice is less costly when compared to performing separate database queries. The worst case scenario, where the application has database queries within a loop is avoided too.
Continue reading Counter Cache
A Different take on the normal “Website Transfer Guide” …
Taking over, or inheriting responsibility for an existing website happens to any web designer or developer at some point. In theory, website transfers sound extremely minor and insignificant – take a backup of the site, re host and away you go. As a result, if you Google something generic like “transfer web site” you’ll get lots of guides that are technically correct but rarely work in theory, as external factors have a big part to play. For instance, look at the website transfer guide of 123-reg.It appears transferring a site is a case of following a couple of basic points. It really isn’t! In reality, taking responsibility for a website is an absolute minefield and deceptively complex. A website transfer guide should reflect these complexities. What follows are some points to consider, from the view of a web developer when doing just that.
Continue reading Website Transfer Guide – Common Pitfalls & Solutions
CodeIgniter’s validation library is amazing out of the box and will save any developer an absolute ton of time. However, as CodeIgniter is an MVC framework it’s validation library does encourage data validation directly in controllers – which of course for the “MVC Nazis” out there is against strict MVC principals. So, data validation should strictly happen at the model layer, not in the controller. Moving data validation to the model has a few benefits – it allows your application to follow to coveted “Fat Model, Skinny Controller” pattern and allows you to validate other data types (not just posted data). Again, you can technically keep things neat by saving your validation rules to a config file and keeping validation in the controller, but that still breaks the MVC principals.
Continue reading Validate Data within A Model using CodeIgniter and MY_Model