Github reacts to Facebook, adds reactions

So I just read over at the Laravel News that Github has introduced reactions. The code-sharing, version-control, platform har added reactions to issues and pull-requests, where a lot most the discussions take place. Part of why Github has elected to add reactions is in part due to the “open-letter” by the community, and they wanted to address the problem that many people in fact “react” to issues, pr’s and so on with emoji. This creates a lot of clutter and noise, as the discussion thread is full av emoji and no content. Secondly they also wanted to let people express their feelings more effectively.

Github Reactions

Github Reactions

We’re adding Reactions to conversations today to help people express their feelings more simply and effectively. – Github

And sure, I get all this and it is a good move indeed. However, you saw that coming didn’t you 😉
However, the “reactions” they have chosen. I do really wonder if they’ve done as much research as Facebook did for which emoji, or reactions, they have chosen. Facebook wrote a long post on how, what and why they chose the ones they did. How did Github and up with thump up/down – laugh – confused – heart – hooray?

On the Github blog they do say that:

”We decided to choose reactions that are relevant to the conversations people have on GitHub. :+1::-1::smile::thinking_face::heart::tada: cover the range of reactions our users typically express through comments on GitHub. We’re looking forward to seeing how the GitHub community uses this set of reactions.”

But who says “hooray” for example, really?

And then there is the timing, are they really reacting to the “open-letter” or just copying Facebook.
Oh well, my ramblings, I do like the feature though – nice one octocats!

What’s your take on Github reactions?

Instant Logo Search – find logos and flags of the world

Now this could be a useful link to bookmark for the future!

Laravel password reset caused double password hashing

I recently updated a little weekend project of mine to Laravel 5.2 and started using the re-implemented authentication stuff.
What I hadn’t implemented, or activated, on the site was password resets. Now password resets is sometimes a feature I myself sometimes use a lot, for different reasons and in this particular case I discovered a problem.

Now, when you have a register/login system on your website the passwords should be encrypted, hashed, and so on. How and when this is done is specific to you and your system, one smooth place to add it is on the setPassword method of your User model. This ensures that whenever the password is written to the database it hashed, right.
But here is where the “problem” arose when I activated the password-reset of Laravel (how have I not stumbled on this before?). So when you reset a password out-of-the-box, you get an email with a link -> go to reset page -> post new password -> password gets saved -> you are logged in. Nothing out of the ordinary.

But…
The password gets hashed in the ResetPasswords trait before it is saved, which is all good except if you hash it in the setPassword method. Because now it gets hashed twice and when you try to login you’ll get an error because the passwords will not match. Well luckily there is a simple fix.
In your PasswordController, inside App\Http\Controllers\Auth, add your custom resetPassword method which will override the traits one.

For example:

protected function resetPassword($user, $password)
{
    $user->password = $password;

    $user->save();

    Auth::login($user);
}

If you don’t do your hashing on the User models setPassword method your probably fine. Maybe doing it there is a weird place?
Let me know what you think.

All new heavy featured WordPress 4.4 released

”Don’t you mean feature heavy WordPress 4.4?”
No, actually I don’t. That is because I don’t think there are so many new features (i.e feature heavy) but the ones that came with 4.4 are pretty heavy 😉

Yeah, so WordPress 4.4 got released tonight (swedish time) and it come with som real nice features. The bigger ones are responsive images, embed everything and the long worked on WP-API is finally getting added to core. For now just the infrastructure has been added, but more is coming in upcoming releases. The embed everything means that you now easily can share posts on other WordPress sites with title, excerpt, featured image and can even get links for comments and sharing.

Enough from me, go read the official post on WordPress 4.4 “Clifford”.

OH! btw, this site here is already upgraded to 4.4!

PHP7 has arrived – Rejoice!

Now what does this all mean you ask?
Well if you haven’t heard or read much about PHP7 I can recommend these links to catch up.

PHP.net: Has the changelog and an migration guide.
SitePoint: Find out what’s new with PHP7
Laracasts: Up & running with PHP7

Google Star Wars easter egg

A long time ago at google far, far away…

So as you know, Google does some funny stuff every now and then. Yes I’m talking about the easter egg, often on google.com or YouTube and so on.

Well now it’s time again, so hurry up and:

  1. Go to google.com
  2. Search for ”A long time ago in a galaxy far, far away”
  3. Press enter
  4. ENJOY!
Socialite providers

Providers for Laravel Socialite

A few weeks ago a write an article on how to get started with Laravels Socialite (swedish).
If you are using Socialite you might feel it is a bit light, with just Facebook, Github, Twitter and so on. Fortunately there are awesome people making these kinds of packages just so much better and more useful.

Without further ado, I give you Socialite Providers by DraperStudios. Socialite Providers give you 70+, as of writing,  additional providers for Socialite.

Adding Eloquent to Themosis (wordpress)

At my current job, @NetRelations, I was hired as a PHP/Wordpress developer (and front end dev). So naturally I do WordPress stuff, but working with WP can sometimes feel… Well *sigh*, because of the way the code in the popular, fantastic cms. That is why things like Themosis are so fantastic.

As a fan, user, supporter and Artisan of the great PHP-framewoerk Laravel , Themosis is like a warm, cozy blanket over WordPress! And we are purely talking code now, not the application it self. Themosis implements many features and ideas from Laravel, modern PHP and staying true to everything WordPress.
But this is not an intro to Themosis, this post is about getting more Laravel magic to your WordPress/Themosis setup.

Because yes, there are some things “missing” if you will. At least of your used to building sites and apps with Laravel. So lets get to it and implementing support for using Eloquent.

First we need to add Eloquent to our composer.json file in our root folder. So open your terminal and in your root run.

composer require illuminate/database

You should now see it in your composer file in the “require” object. Now comes the part which I’m not really sure what is the best way or best place to put it. That is loading of Eloquent and handing your database settings to it. I chose to put inside environments config files, so for my local installation I put the following code in side “config/environments/local.php”.

use Illuminate\Database\Capsule\Manager as Capsule;

$capsule = new Capsule;

$capsule->addConnection([
    'driver'    => 'mysql',
    'host'      => getenv('DB_HOST'),
    'database'  => getenv('DB_NAME'),
    'username'  => getenv('DB_USER'),
    'password'  => getenv('DB_PASSWORD'),
    'charset'   => 'utf8',
    'collation' => 'utf8_unicode_ci',
    'prefix'    => ''
]);

$capsule->setAsGlobal();
$capsule->bootEloquent();

What are the getenv() things in that code. Well if you use Themosis or open the file I mentioned, you will see that they are used for the WordPress database settings. So you can just reuse those code parts.
One little disclaimer here right up front. You cannot remove the WP db-settings, as far as I know because WordPress needs a its database connection.

We have Eloquent added, installed and booted – now what?

Now we can just create our models and make them extend Eloquent, like this.

<?php
use Illuminate\Database\Eloquent\Model as Eloquent;

class PostModel extends Eloquent{

	protected $table = 'wp_posts';
	protected $primaryKey = 'ID';

}

Then in your controller you could do something like

public function allPosts(){
  $allposts = PostModel::all();

  return $allposts;
}

Not the most beautiful code but you get the gist.

So yeah that was basically it for adding Eloquent to your Themosis based WordPress installation! 🙂
But wait, just one more thing 😉

This last tip is something I’m going to try to make time to make a pull request for and implemented into Themosis.
So what I wanted when I added Eloquent to my project was to use the relationship features of it. At first I didn’t really get them to work as Eloquent (or what not) couldn’t figure what model I was referencing. But after a few minutes I figured I’d try something that I had tried earlier for another reason but failed. You see to be able to use your controllers and models in Themosis you have to ad them to an config file which in turn loads them in your app. Easy enough but a bit cumbersome, *cough* when your used to autoloading a la PSR4 *cough*.

Said and done, opened my composer.json and added a PSR-4 section to the autoload object and pointed it to my “theme/app” folder, like so.

[json]
“autoload”: {
“psr-0”: {
“Thms”: “library”
},
“psr-4”: {
“MyTheme\\”: “htdocs/content/themes/my-theme/app”
}
},
[/json]

Now you just need to add a namespace declaration to your models, and use the complete path when adding a relation.

<?php namespace MyTheme\models
use Illuminate\Database\Eloquent\Model as Eloquent;

class PostModel extends Eloquent{

	protected $table = 'wp_posts';
	protected $primaryKey = 'ID';

   public function tags() {
   /* Given that the related models name is TagModel */
      return $this->hasMany('MyTheme\Models\TagModel');
   }

}

As simple as that, don’t you think. And as a bonus, you don’t need to define your models in the “loading.config.php” file anymore as they are autoloaded. at least I don’t think you do, works for me so far.
Same should apply for your controllers, just don’t forget to put in the namespace declaration and “use” the files you, well use inside your class!

That is all for now. Comments, suggestions and improvements on the above is welcome.

Read more about EloquentThemosis