PHP Internals News: Episode 84: Introducing the PHP 8.1 Release Managers – Derick Rethans

PHP Internals News: Episode 84: Introducing the PHP 8.1 Release Managers

In this episode of “PHP Internals News” I converse with Ben Ramsey (Website, Twitter, GitHub) and Patrick Allaert (GitHub, Twitter, StackOverflow, LinkedIn) about their new role as PHP 8.1 Release Managers, together with Joe Watkins.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

Derick Rethans 0:14

Hi, I’m Derick, welcome to PHP internals news, a podcast, dedicated to explaining the latest developments in the PHP language. This is episode 84. Today I’m talking with the recently elected PHP 8.1 RMs, Ben Ramsey and Patrick Allaert. Ben, would you please introduce yourself.

Ben Ramsey 0:34

Thanks Derick for having me on the show. Hi everyone, as Derick said I’m Ben Ramsey, you might know me from the Ramsey UUID composer package. I’ve been programming in PHP for about 20 years, and active in the PHP community for almost as long. I started out blogging, then writing for magazines and books, then speaking at conferences, and then contributing to open source projects. I’ve also organized a couple of PHP user groups over the years, and I’ve contributed to PHP source and Docs and a few small ways over the years, but my first contributions to the project were actually to the PHP GTK project.

Derick Rethans 1:14

Oh, that’s a blast from the past. You know what, I actually still run daily a PHP GTK application.

Ben Ramsey 1:21

Oh, that’s interesting. What does it do?

Derick Rethans 1:23

It’s Twitter client.

Ben Ramsey 1:24

Did you write it.

Derick Rethans 1:26

I did write it. Basically I use it to have a local copy of all my tweets and everything that I’ve received as well, which can be really handy sometimes to figuring out, because I can easily search over it with SQL it’s kind of handy to do.

Ben Ramsey 1:41

It’s really cool.

Derick Rethans 1:42

Yep, it’s, it’s still runs PHP 5.2 maybe, I don’t know, five three because it’s haven’t really been updated since then.

Ben Ramsey 1:49

Every now and then there will be some effort to try to revive it and get it updated for PHP seven and eight, but I don’t know where that goes.

Derick Rethans 1:59

I don’t know where that’s gone either. In this case, for PHP eight home there are three RM, there’s Joe Watkins who has done it before, Ben, you’ve just introduced yourself, but we also have Patrick Allaert, Patrick, could you also please introduce yourself.

Patrick Allaert 2:13

Hi Derick, thank you for the invitation for the podcast, my name is Patrick Allaert. I am a Belgian freelancer, living in Brussels, and I spent half of my professional time as a IT architect and/or a PHP developer, and the other half, I am maintaining the PHP extension of Blackfire, a performance monitoring solution, initiated by Fabien Potencier.

Derick Rethans 2:39

Truncated by Planet PHP, read more at the original (another 20272 bytes)

One year of functional PHP; now in Russian! – larry@garfieldtech.com

One year of functional PHP; now in Russian!

Submitted by Larry on 11 May 2021 – 8:14pm

A year ago, I published my first solo book, Thinking Functionally in PHP. The reception has been extremely positive; almost everyone that’s read it (that has bothered to talk to me about it) has found it clear, helpful, and enlightening. Mission accomplished!

To celebrate the one year anniversary of the book’s publication, I am happy to make two announcements.

First, Thinking Functionally in PHP is now available in Russian! The translation is by Alexey Pyltsyn, who is responsible for the Russian translation of the PHP documentation as well as numerous other tech book translations.

Xdebug Update: April 2021 – Derick Rethans

Xdebug Update: April 2021

Another monthly update where I explain what happened with Xdebug development in this past month. These will be published on the first Tuesday after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 93% towards my $1,000 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In April, I worked on Xdebug for about 35 hours, with funding being around 28 hours.

Xdebug 3.1

I have continued to work on the Xdebug 3.1 tasks. I have added an API to that tools can query which modes Xdebug has enabled, no matter how; added compression for profiling file, which both PhpStorm and KCacheGrind/QCacheGrind can read, and I’ve made some changes to how errors are reported if the Xdebug log is active.

To enable Xdebug Cloud to be used in more situations, it is now possible to replace the “session name” that browser extensions use to activate Xdebug with your Cloud ID. By setting the Cloud ID through the browser extension (or with the GET/POST) parameters, you can now share a single development server with multiple developers all using their own IDE through Xdebug Cloud.

Xdebug Videos

I also continued to produce a few more videos on how to use Xdebug.

The first of these is Profiling with Xdebug in Docker, and the second one is Debugging Unit Tests with PhpStorm on Linux. I will continue to release more videos on YouTube, where you can also find other Xdebug videos in the Xdebug 3 play list.

If you would like to see a 5 to 10 minute long video on another specific topic, feel free to email me at derick@xdebug.org.

Xdebug Cloud

Xdebug Cloud is continuing to operate as Beta release, and provides an easy way to debug your PHP applications with Xdebug, without having to deal with complexities with regards to networking.

Packages start at £49/month, and revenue will also be used to further the development of Xdebug.

If you want to be kept up to date with Xdebug Cloud, please sign up to the mailinglist, which I will use to send out an update not more than once a month.

JWT should not be your default for sessions – Evert Pot

Cookies

When designing web applications, (especially the traditional html kind),
you will at one point have to figure out how to log a user in and keep them
logged in between requests.

The core mechanism we use for this are cookies. Cookies are small strings sent
by a server to a client. After a client receives this string, it will repeat
this in subsequent requests. We could store a ‘user id’ in a cookie, and
for any future requests we’ll know what user_id the client was.

Cookie: USER_ID=123

But this is very insecure. The information lives in the browser, which means
users can change USER_ID and be identified as a different user.

Sessions

The traditional way to solve this is what’s known as a ‘session’.
I don’t know what the earliest usage of sessions is, but it’s in every web
framework, and has been since web frameworks are a thing.

Often, sessions and cookies are described as 2 different things, but
they’re really not. A session needs a cookie to work.

Cookie: MY_SESSION_ID=WW91IGdvdCBtZS4gRE0gbWUgb24gdHdpdHRlciBmb3IgYSBmcmVlIGNvb2tpZQ

Instead of a predictable user id, we’re sending the client a completely random
session id that is impossibly hard to guess. The ID has no further meaning, and
doesn’t decode to anything. This is sometimes called an opaque token.

When a client repeats this session id back to the server, the server will look
up the id in (for example) a database, which links it back to the user id.
When a user wants to log out, the session id is removed from the data storage,
which means the cookie is no longer associated with a user.

Where is the session data stored?

Languages like PHP have a storage system for this built in, and will by default
by default store data in the local filesystem. In the Node.js ecosystem, by
default this data will be in ‘memory’ and disappear after the server restarts.

These approaches make sense on developer machines, or when sites were hosted
on long-lived bare-metal servers, but these days a deploy typically means
a completely fresh ‘system’, so this information needs to be stored in a place
that outlives the server. An easy choice is a database, but it’s common for
sites to use systems like Redis and Memcached, which works for tiny sites, but
still works at massive scales.

Encrypted token

Over 10 years ago, I started working a bit more with OAuth v1 and similar
authentication systems, and I wondered if we could just store all the
information in the cookie and cryptographically sign it:

Question about session tokens on Stack Overflow

Despite getting some good answers, I didn’t go through with it as I didn’t
feel confident enough in making this secure, and I felt it required a better
understanding in crypto than I did.

A few years later, we got JWT, and it’s hot shit! JWT itself is a standard for
encrypting/signing JSON objects and it’s used a LOT for authentication.
Instead of an opaque token in a cookie, we actually embed the user_id again,
but we include a signature. The signature can only be generated by the server,
and it’s calculated using a ‘secret’ and the actual data in the cookie.

This means that if the data is tampered with (the user_id was changed), the
signature no longer matches.

So why is this useful? The best answer I have for this, is that it’s not
needed to have a system for session data, like Redis or a database. All the
information is contained in the JWT, it means your infrastructure is in
theory simpler. You’re potentially making fewer calls to a data-store on
a per-request basis.

Drawbacks

Theres are major drawbacks to using JWT.

First, it’s a complicated standard and users are prone to get the settings
wrong. If the settings are wrong, in the worst case it could mean that anyone
can generate valid JWTs and impersonate anyone else. This is not a
beginners-level problem either, last year Auth0 had a bug in one of
their products that had this very problem.

Truncated by Planet PHP, read more at the original (another 7263 bytes)

I made a TYPO – larry@garfieldtech.com

I made a TYPO

Submitted by Larry on 5 May 2021 – 4:55pm

I am a firm believer in “anything worth doing is worth doing right.” So when given the opportunity to get paid to do that, it’s hard for me to say no. Which is why I didn’t.

I am happy to report that this is my first week in my new role as Staff Engineer on the TYPO3 core contributors team.

Continue reading on PeakD.

Laravel: Marking notification e-mails as automatically submitted – Christian Weiske

Process mails from web applications like e-mail address verification and password reset mails should be tagged as “automatically submitted” so that mail servers do not respond with “Out of office” or vacation notification mails.

The official standard for that is RFC 3834: Recommendations for Automatic Responses to Electronic Mail, which defines an e-mail header Auto-Submitted: auto-generated for our use case.

Laravel notifications

E-mails automatically built from Laravel notifications can be modified to contain that header: Inside the toMail() method, register a modification callback for the MailMessage class:


<?php
namespace App\Notifications; class ResetPassword extends \Illuminate\Notifications\Notification
{ /** * Build the mail representation of the notification. * * @param mixed $notifiable * @return MailMessage */ public function toMail($notifiable) { return (new \Illuminate\Notifications\Messages\MailMessage) ->withSwiftMessage([$this, 'addCustomHeaders']) ->subject(_('Reset your password')); } /** * Add our own headers to the e-mail */ public function addCustomHeaders(\Swift_Message $message) { $message->getHeaders()->addTextHeader('Auto-Submitted', 'auto-generated'); }
}

PHP Internals News: Episode 83: Deprecate implicit non-integer-compatible float to int conversions – Derick Rethans

PHP Internals News: Episode 83: Deprecate implicit non-integer-compatible float to int conversions

In this episode of “PHP Internals News” I talk with George Peter Banyard (Website, Twitter, GitHub, GitLab) about the “Deprecate implicit non-integer-compatible float to int conversions” RFC that he has proposed.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

Derick Rethans 0:14

Hi, I’m Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 83. Today I’m talking with George Peter Banyard, about another tidying up RFC, George, would you please introduce yourself?

George Peter Banyard 0:31

Hello, my name is George and I work on PHP in my free time.

Derick Rethans 0:35

Excellent. I was just talking to Larry Garfield, and he was wondering whether you or himself, are the second often guests on this podcast, but I haven’t run a stats. But it’s good to have you on again. Following on for from other numeric RFCs, so to speak. This one is titled deprecate implicit non integer compatible floats to int conversions. That is a lovely small title you have come up with.

George Peter Banyard 1:01

Yeah, not the best title.

Derick Rethans 1:03

What is the problem that this RFC is trying to solve, or rather, what’s the change that is in this RFC is trying to solve?

George Peter Banyard 1:11

Currently in PHP, which is a dynamic language, types are not known at the statically at compile time, so it’s so everything’s mostly runtime. And most type conversions are relatively sane now in PHP 8, because like numeric strings have been kind of fixed. But one last standing issue is that floats will pass an integer check, without any notices or warnings. Although floats, don’t usually fit in integer will have like extra data which can’t be represented as an integer. For example, they can have a fractional part, or they can be infinity, or not a number if you divide, like infinity by infinity, or 0 over 0 or other things like that.

Derick Rethans 1:55

These are specific features of floating point numbers on computers?

George Peter Banyard 1:59

Yes.

Derick Rethans 2:00

Is there any prior work that is RFC is building on top of

George Peter Banyard 2:03

It builds up on top on the saner numeric string RFC, because it tries to like make the whole numericness of PHP, as a concept better and like less error prone, but in essence it’s mostly self contained. If you use a floating point number, were you should be using an integer. If the floating point number, is considered an integer because it only has like decimal zeros, and it fits in the integer range, then you’ll have like no error. So if you use 15.0 as an array key, it gets converted to 15, you’ll get don’t get any error because it’s like well it’s just 15 like it doesn’t mind. But if you do 15.5, then you’ll get like a, like a deprecation notice which will tell you it’s like, well, here’s the key gets implicitly converted, you should be aware of this because if you use 15 somewhere else, you’d be overriding the value.

Derick Rethans 2:54

Truncated by Planet PHP, read more at the original (another 16989 bytes)

Inside our onboarding program or how we welcome new Liipers – Liip

Starting at a new company is a huge challenge. We feel you – been there, done that! 😉 That is why we have an onboarding program in place, which makes you feel part of the Liip family from day 1, hopefully. Your recruitment process was a success, let’s make your onboarding great too. So let’s jump right in!

Meet your onboarding buddy

Céline, Hendrik, Janina, Stefan… these are four of the almost twenty onboarding buddies at Liip spread over all the six locations. And you will get a buddy too! Your onboarding buddy is your go-to person, your sparring partner for social and cultural aspects at Liip.

They are usually based in the office you are joining, while not part of your work team. Additionally, you get a work buddy for work-related topics who tell you all about the projects you will work on. Responsibility and autonomy are key at Liip. We will support you to find your way and embrace our values.

Your buddies will guide you through the onboarding program. Providing you with an overview of the company, our processes and tools. Together, you will define your trial period goals and regularly meet to reflect and share impressions and feedback.

Last but not least, social gatherings! They are part of the #liipway, and your onboarding buddy aims for making you feel welcome at the (online) apéro, game session or yoga class – if you wish to take part. We are striving for a successful and pleasant integration to Liip for you.

At the end of your three-month trial period, you will be invited to the so-called “trial period meeting”. This is a dedicated time to identify what has been moving you forward, what has been holding you back and what opportunities and challenges might arise. You will self-reflect and get feedback from peers as well as your onboarding buddy. In other words, this is our ritual to finalize the onboarding process and confirm your hiring.

Go with the flow

Everything is organized so that you can “just” surf the wave. Technically speaking, you will get what you need to work, such as a brand-new laptop, an ergonomic desk and chair, a monitor, a keyboard, a mouse, etc. All of it is organized on-site or sent to your place (maybe not the desk nor the chair 😉 ) in case you start your onboarding program remotely.

Thanks to a clear and easy to follow checklist (aka your onboarding kanban board), you have an overview of your progress within the onboarding program at any time. Where to get support, how to contribute to the external communication of Liip, how our salary system works, and so much more will be taught to you.

Trainings are part of the program too. Holacracy, Agility and Feedback trainings are on the menu. And you will learn more about your personal education budget.

Take part in the #liipway

All you need is curiosity and enthusiasm. Let yourself be guided, and enjoy the ride! We can only advise you to participate in social and health activities to get a taste of the #liipway, either on-site (as soon as this will be possible again) or online like coffee breaks, game sessions, yoga or boot camp courses, …and apéros! Our tool meet-a-liiper-with-donut makes meeting new work colleagues from all over Liip, even during remote times, a walk in the park.

Don’t be shy and dare to ask questions (all of them!). How you experience the onboarding program has the utmost importance to us. Please give us your honest feedback, so that we keep on improving it.

PHP 8.1: `never` Return Type is Dangerous – Sergey Mitroshin

There are many features already introduced in PHP 8.1, and among them the new never return type:

function doSomething(): never { // do something die();
}

The idea is pretty straightforward: if the execution flow is never supposed to leave the function, it should be marked as never. If the execution flow somehow reaches the end of the function, PHP will throw an error.

Although it seems to me like a good idea, there’s a hidden catch we need to be cautious about.


Continue reading

PHP Internals News: Episode 82: Auto-Capturing Multi-Statement Closures – Derick Rethans

PHP Internals News: Episode 82: Auto-Capturing Multi-Statement Closures

In this episode of “PHP Internals News” I chat with Larry Garfield (Twitter) and Nuno Maduro (Twitter, GitHub, Blog) about the “Auto-Capturing Multi-Statement Closures” RFC.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

Derick Rethans 0:14

Hi, I’m Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 82. Today I’m talking with Nuno Maduro and Larry Garfield. Nuno, would you please introduce yourself?

Nuno Maduro 0:30

Hi PHP developers. My name is Nuno Maduro, and I am software engineer at Laravel, the company that owns the Laravel framework, and I have created multiple open source projects for the PHP community, such as Pest PHP, Laravel zero, collusion and more.

Derick Rethans 0:48

Alright, and Larry, could you please follow up on that.

Larry Garfield 0:51

Hello world, so I’m Larry Garfield. You may know me from several past podcasts here, various work in the PHP fig, and all around gadfly and nudge of the PHP community.

Derick Rethans 1:03

Good to have you again Larry and good to have you here today, Nuno. The RFC, that we’re talking about here today is to do with closures, and the title of the RFC is auto capturing multi statement closures, which is quite a mouthful. Can one of you explain what this RFC is about?

Nuno Maduro 1:20

As you said, the RFC title is indeed auto capturing multi statement closures. But to make it simple, we are really talking about adding multi line support to the one line arrow functions that got introduced it, in PHP 7.4. Now, this new multi line arrow functions have exactly the same features as the one line arrow functions, so they are anonymous, locally available functions; variables are auto captured lexically meaning that you don’t actually need the use keyword to manually import the use of variables, they just get auto captured from the outer scope. And the only difference really is one line arrow functions have a body with a single expression. This RFC actually allows you to use a full statement list that possibly ends with a return.

Derick Rethans 2:18

Excellent, what the syntax that you’re proposing here?

Nuno Maduro 2:22

Well, as you may know, one line arrow functions have the syntax, which is fn, parameter list, and then that arrow expression thing, and this new RFC proposes that, optionally, developers can pass a curly brackets with statements, instead of having that arrow expression syntax. Now, this curly brackets with statements, simply denotes a statement list that potentially ends with a return. Concerning the Auto Capture syntax, we will be just reusing the Auto Capture syntax and feature that already exists on one line arrow functions, meaning that you don’t need the use keyword to manually import variables. And of course, the syntax itself, in the in the feature, works the exactly same way. Concerning the syntax, it’s also important to mention that this RFC was done in combination with the short functions RFC from Larry, but I think I’m going to let Larry speak about that later on this episode.

Derick Rethans 3:26

What’s the main idea behind wanting to introduce this auto capture m

Truncated by Planet PHP, read more at the original (another 20326 bytes)