I found myself wanting to validate an input field that will be used when inserting the POST values in a table. That input field would have to be a DATETIME type of value. That is to say that if someone will fill the value of an input field, let’s name the input field “published_at”, that value would have to have a DATETIME format: 2015-05-18 15:10:29. Continue reading
(created at: May 07, 2014; last update: December 15, 2015)
It’s been almost a year since I’ve posted a tutorial (Multi-level menu in PHP – how to do it without killing yourself or the database in the process) about how do create a multi-level menu in PHP, but in all that time I’ve never seen anyone complaining about some of the weak points of my approach. Continue reading
Well, it’s that time when someone is bombarding you with spam or, who knows, is trying to look for vulnerabilities by filling your site’s form with all sorts of garbage strings. And then the whole Earth falls on you. What to do then? Continue reading
Revisiting MY_Model in CodeIgniter: Copying from Jamie Rumbelow and looking at Eloquent and Establishing relationships between tables inside the MY_Model in CodeIgniter (1): has_one and has_many relations were really long tutorials, but we ended up creating a good MY_Model, so I thought “why not post this on Github?”
And I did. You can find CodeIgniter MY_Model at the following repository: https://github.com/avenirer/CodeIgniter-MY_Model
I sure hope you will use it and report me any issues you encounter. if you feel smart, you can also do some pull request. I’ll be happy to merge them if they look good.
The instructions about using the MY_Model can be found on Github. Also, you can look and the tutorials I’ve mentioned earlier. Be careful though, as the final code can be different than what you’re seeing on the Github repository.
Please give it a try at:
Well… the previous tutorial (Revisiting MY_Model in CodeIgniter: Copying from Jamie Rumbelow and looking at Eloquent) was a reeeally long one, so I decided to create a new tutorial that will continue that one. This means that the current tutorial is still taking into consideration the Jamie Rumbelow’s base model, but also keeps looking at Laravel’s Eloquent. Continue reading
Please give it a try at:
This tutorial is a work in progress created at 2015.02.11 and updated at 2015.02.17. It’s tested with CodeIgniter 3.
Well… It’s that time when we should stop repeating ourselves. The DRY philosophy tells us that maybe we should use our time doing things faster than repeating the same steps for basic CRUD in our models. I’ve talked about the MY_Model subject in the past, but we can improve a lot on that.
A few years ago, Jamie Rumbelow wrote a great book named CodeIgniter Handbook in three volumes, in which he manages to bring Ruby philosophy in the world of CodeIgniter. In the book he talks about Convention over Configuration, trying to apply design principles like Don’t Repeat Yourself (DRY) and RESTful style to CodeIgniter. Continue reading
The CodeIgniter’s upload library is great. But it only works for single file uploads. So I thought that an extension to allow for multiple files upload would be a nice addition to CI’s upload library. Hence, allow me to present you MY_Upload. The extension is hosted on Github. So go there and download it. Continue reading
Please allow me to introduce to you another one of my libraries. This one is good for manipulating images. Every site that has images for products/posts/pages use at least two different sizes (if not more…): one for a thumbnail and one for featured images (and maybe one for a slideshow, etc.).
This library will allow you to automatically create the different dimensions of the images right after you upload it. All you have to do is set the width and height of the images you want created and give the library the path to the image that you want processed. Continue reading
We said good-bye to the PEAR packages, and hello to Composer. All is working fine at my home computer, but then I go to work and try to make Composer work without any luck. So, what happened? Continue reading
When I create some sort of admin panel, I usually want to know not only when a user created or edited an item (post), but also who that user was.
Considering this, I always add two additional columns to my tables: created_by and updated_by. This, along with the timestamps from Laravel, is the best way to keep track of latest changes of a database record. Continue reading