Remove the username requirement from Zizaco Confide

These days it’s very uncommon for websites to user usernames and most sites just use the user’s email address.

Laravel has many, many very handy packages we can use to quickly get up and running and save us countless hours when developing a website but sometimes they do not do exactly what we want. In this case I relied on a package called Confide by Zizaco, commonly referred to as Zizaco/Confide. It started off pretty great with me having user creation, login, password reminders etc all working within 30 minutes. However, Zizaco/Confide heavily relies on the existance of a username for creating users and logging in. To get around this you will have to extend Zizaco\Confide\UserValidator and override $rules and also extend Zizaco\Confide\EloquentRepository and override the function getUserByEmailOrUsername.

To do this you can create a file in app/controllers with two classes in it and modify app/start/local.php to re-bind the Confide classes to your new ones so the original classes get overridden.

app/controllers/ConfideUsernameFix.php

app/start/local.php

UPDATE: Had to override the function validateIsUnique as well which required me to “use Zizaco\Confide\ConfideUserInterface;” to get it to work. Code fragment updated to reflect the new situation.

ERR INCOMPLETE CHUNKED ENCODING with Nginx

If you ever experience the error ERR_INCOMPLETE_CHUNKED_ENCODING in WordPress (you should be able to find this in your Nginx error log) then you should check the following things:

  • Nginx and PHP-FPM should both be run as the same user
  • The directory /var/lib/nginx and all underlying directories should be chowned to that user

I my case Nginx and PHP-FPM were both running as Apache, but the directory /var/lib/nginx was owned by nginx:root. This meant the dir has to be chowned to apache:apache to fix the problem:

Don’t forget to restart nginx & php-fpm to be on the safe side.

Pass Validation Errors to the Master Template in Laravel

laravelSo I am developing an invoicing system in Laravel and ran into the problem that I couldn’t figure out how to pass validation errors to the master template in Laravel. Normally you can only Redirect::to()->withErrors($validator); and I wasn’t trying to Redirect but output them straight to the View. After having read a few silly solutions which involved View::make()->with(‘errors’, $errors); and then writing a whole new foreach loop in the view instead of the template. That is clearly not an efficient solution since I would mean copy/pasting code from the template to the view.

Doing the following does not work:

So I figured out you can share a variable across all currently loaded views/templates.

Here’s the piece of code that works for me now:

So I get the validator messages and store those in a variable $messages. I then “share” that variable as $errors across all views and my template picks it up in the following piece of code:

CentOS 7 WordPress with Percona and Redis

Moved logo-centos-7distro again because I somehow managed to break MariaDB on Ubuntu.. So instead I’m back to Percona on CentOS, which I upgraded to v7 now. CentOS 7 WordPress with Percona and Redis! Mind you I am not running HHVM anymore so the site will be slower. Turns out there’s a memory leak when it comes to Crayon, the syntax highlighting plugin I use. I have to look for a nice caching solution, preferably using Redis..

UPDATE: Found my redis solution! https://github.com/BenjaminAdams/wp-redis-cache
Without being logged in the blog loads in 13ms now, that’s even faster than varnish :)

UPDATE: Turns out I was overloading my VPS and the dreaded OOM killer struck and killed Percona. So I’ve upgraded to a 2GB VPS and I’ve added DataDog monitoring to Nginx, Percona and Redis just to see what’s going on. Here’s an example of my dashboard at DataDog. It’s a bit of a build it yourself NewRelic and free up to 5 hosts!

 

 

Magento create slug

MU-SlugCreating a Magento slug from any type of string or bunch of words is really easy. Magento has a few built in functions to deal with just that and they take any type of character as input.

As described by Wikipedia:

Some systems define a slug as the part of a URL which identifies a page using human-readable keywords.[4][5] It is usually the end part of the URL, which can be interpreted as the name of the resource, similar to the basename in a filename or the title of a page. The name is based on the use of the word slug in the news media to indicate a short name given to an article for internal use.

Slugs are typically generated automatically from a page title but can also be entered or altered manually, so that while the page title remains designed for display and human readability, its slug may be optimized for brevity or for consumption by search engines. Long page titles may also be truncated to keep the final URL to a reasonable length.

Slugs are generally entirely lowercase, with accented characters replaced by letters from the English alphabet and whitespace characters replaced by a dash or an underscore, in order to avoid being encoded. Punctuation marks are generally removed. For example:

Original title: This, That & the Other! Various Outré Considerations
Generated slug: this-that-other-various-outre-considerations

At work we even use it to generate CSS classes since they are also safe in that aspect. I have copied it into a simple function, since I used it for an import script but if you are just working in Magento itself you can of course just call the Mage:: line by itself.

Class undefined: Mage_Googlecheckout_Helper_Data

t-google-404-1299071983This is a common problem you will experience after updating Magento past 1.7.0.2. There are a few Google Checkout files which are not necessary anymore and if they still exist Magento will spit out an error (and possibly a white screen) after the update. I usually find the error in system.log and it usually looks like this:

This has been documented in the knowledgebase here:

http://www.magentocommerce.com/knowledge-base/entry/ce-18-later-release-notes

The sollution is quite simple, go to the following directory and delete all the files EXCEPT config.xml:

So that should be the following files:

After deleting those files your admin pages should work again. You might have to clear your cache as well.

Working Drupal 7 Nginx Configuration

This config is working for me including regeneration of style images after being flushed.