On the SitePoint PHP blog there's a new tutorial posted from Christopher Vundi showing you how to create a password-less login system using "magic links". These links allow users to log into a service without requiring a password using a one-time code and a special URL.

Authentication is something that has evolved over the years. We have seen it change from email – password combination to social authentication, and finally password-less authentication. Actually, more like an “email only” authentication. In the case of a password-less login, the app assumes that you will get the login link from your inbox if the email provided is indeed yours.

[...] In this tutorial, we are going to implement such a system in a Laravel app. The complete code can be found here.

The tutorial then walks you through some of the setup of the application environment - creating the Laravel project, building out the database and running the "make:auth" to generate related controllers/views/models. They show you how to change the login link to point to the new "magic link" functionality and the matching controller and view. The tutorial then shows how to generate the tokens, email them to the user with the special URL and validate them once they come back in.

php[architect] Magazine has just published their latest issue for July 2016: Harnessing Magic. This latest issue features articles like:

• "RegEx is Your Friend" (Liam Wiltshire)
• "Removing the Magic with Functional PHP" (David Corona)
• "Implementing Cryptography" (Edward Barnard)
• "Reference Counting : The PDO Case Study" (Gabriel Zerbib)

There's also all of the usual columns from some of the regular authors, the "Education Station", "Community Corner" and the "Security Corner". If you're interested in the content but just want a sample, be sure to check out this month's free article covering mailing lists and MailChimp. You can pick up either just this issue or a full year subscription directly from the php[architect] website.

One of the latest offerings in the Laravel ecosystem, Laravel Valet, was released this past week. It makes setup of new applications simpler and even allows tunneling back from the public web to a local system for easy sharing. In this post to his site Mohamed Said takes a look at the "magic" behind Valet and how it does what it does.

So yesterday Taylor Otwell and Adam Wathan released Laravel Valet, it's simply a tool that helps OS X users easily run their websites locally for development purposes, without the need to configure anything each time a new project needs to be created.

The idea behind valet is that it configures PHP's built-in web server to always run in the background when the operating system starts, then it proxies all requests to a given domain to point to your localhost 127.0.0.1

He starts by helping you get the tool downloaded (via Composer) and what happens when you run the valet install command. He gets into the detail of each piece that valet sets up:

• the OS X daemon to run the PHP built-in server
• the Valet configuration files
• Dnsmasq (a DNS server)

He then talks about how handles the requests for your local ".dev" sites and the "drivers" it uses to decide which site to serve up.

NetTuts.com has posted the second part of their "Refactoring Legacy Code" series today continuing on from their beginning of the series. They continue the refactor of their "trivia" application.

Old code. Ugly code. Complicated code. Spaghetti code. Jibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. We first met our legacy source code in our previous lesson. [...] The time for the first changes have come and what better way to understand a difficult code base than start to extract magic constants and strings into variables? These seemingly simple tasks will give us greater and sometimes unexpected insights into the inner workings of legacy code. We will need to figure out the intentions of the original code author and find the proper names for the pieces of code that we've never seen before.

They talk about refactoring out things like "magic strings" and other hard-coded return values and checks. They mention updating the tests to reflect these changes while keeping an eye out for "magic constants" as well.

In the latest post to his MaltBlue.com site Matthew Setter takes a look at magic methods. He tries to answer a few basic questions about them - are they worth using and can you truly test effectively when they're in use.

As a freelance Zend Framework developer, I’m always looking to improve the quality of the applications I produce. So over the last 6 – 12 months, I’ve been learning as much as possible about testing. During this time, I’ve found the way I code’s dramatically changing (and improving). [...] In a recent development session, I attempted to test some of my ZendDb based classes, specifically the code which used the magic methods for dynamically building where clauses. [...] I can’t speak for what it’s like using PHPUnit’s mock objects, as I always use Mockery instead. But after attempting to do so in Mockery, I hit a stumbling block when trying to test the chained call.

His example is a call to "lessThanOrEqualTo" to create his where clause that makes use of the "__get" magic method to get and return "Where" object. After some research (and conversations on IRC) he started wondering if the magic methods were worth the trouble they may cause during testing. He references this post and lists several of the comments made about their use, most of them not in favor.

Russell Walker has a recent post to his site looking at different ways to work with class properties including using them as public properties or using getters and setters.

Opinion seems to be divided on whether it is good practice to use public properties in PHP classes, or whether to use getter and setter methods instead (and keep the properties private or protected). A sort of hybrid third option is to use the magic methods __get() and __set(). As always, there are advantages and disadvantages to each approach, so let's take a look at them.

He breaks the rest of the post up into three sections, each with a bit of a code example and the common advantages/disadvantages. It's a good overview of the three types and, in the end, it's mostly about what works for your applications. What's his favorite?

My choice then is to use public properties most of the time, but getters and setters for critical settings that I feel need stricter control, would benefit from lazy loading, or that I want to expose in an interface.

Lorna Mitchell has a new post showing nine of the magic methods that are included in PHP by default (like __construct, __get and __set) including a few you may not have used before.

The "magic" methods are ones with special names, starting with two underscores, which denote methods which will be triggered in response to particular PHP events. That might sound slightly automagical but actually it's pretty straightforward, we already saw an example of this in the last post, where we used a constructor - so we'll use this as our first example.

She includes details (and some code samples) for these methods:

• __construct
• __destruct
• __get
• __set
• __call
• __sleep
• __wakeup
• __clone
• __toString

You can find out about these and a few others in this page of the PHP manual.

There's a feature that's usage has been showing up more and more in software projects (both open source and not) that allows you to install their system with a single line command, usually involving curl and maybe piping it to a shell. In this recent post Michael Maclean takes a look at this trend and some of the possible pitfalls of the approach.

There has been a trend in the last while for various bits of useful software to have a one-line shell command recommended as the installation method. The usual form of this is to pipe something like curl or wget to some interpreter, be it bash, php, ruby, or some such. [...] This [type of] command takes the output of curl and pipes it straight to bash. I have several issues with this.

His three main points center around the fact that you cannot inspect the code before executing it with this method, that you can't verify the source of the code and that it teaches users bad habits of trusting in "magic commands" like these.

Pim Elshoff has a new post to his blog that shares his preference on typing (keystrokes, not variables) in applications (hint: he likes it):

We sometimes conceive of ideas that are arduous to express in code. Like persisting data, or some other uncommon task (sarcasm). It's not difficult, but it takes a lot of keystrokes to write. Being problem solvers, we find it difficult doing this kind of manual labour, especially when machines can do it for us. Still, I would like to take this opportunity to say that typing rocks and solutions that save typing suck.

He talks about the abstraction that frameworks provide (less typing, more work) and and some of the "magic" that comes with them. He gives specific examples of some of his pervious experience with frameworks (including some pains with Symfony2) and how some of the magic he's seen is easy to write but hard to read.

On the Refulz.com blog there's a recent post introducing the __toString() magic method in PHP. This handy method allows you to define how to return an object when it's referenced as a string.

We started the study of PHP magic methods by learning about __get() magic method. [...] PHP is loosely typed language and same variable can be used or referred as string, number or object. The __toString() method is called when the code attempts to treat an object like a string. This function does not accept any arguments and should return a string.

Some quick code is included showing how it works - returning a combined string made from two private class properties when the object ($obj) is echoed out. They also show multiple ways of using the method in both pre- and post-PHP 5.2.