On the Pineco.de blog they've posted a tutorial showing how to use Guzzle to subscribe users to a Mailchimp mailing list in a Laravel application. The technique isn't specific to a Laravel application and can be adapted relatively easily for other framework/application types.

Managing users and mailing lists are not a that painful nowadays. Since we have excellent services that can cover all the needs we have, we don’t need to worry about it too much. But still, let’s take a look at how can we handle user subscriptions when Laravel fires different events.

In the tutorial, the request is sent to Mailchimp via the user registration event fired when a new user signs up for the site. They include the code to create the listener and register it in the Laravel configuration. They've also included the code that will be used when the event is fired, sending a message to the Mailchimp API with a "subscribed" status and the user information.

One of the comments that we get here on PHPDeveloper.org is that it's hard to keep up with all of the posts each day and not miss anything. For those on Twitter, we do auto-post to the @phpdeveloper Twitter account but not everyone is on Twitter. There's also our RSS feed for those that are more feed-inclined but there's been a piece missing.

If RSS feeds or Twitter weren't really your thing, you'd need to visit the site regularly just to see all of the posts. Not everyone has time for that so we're introducing yet another method that you, our loyal readers, can get the latest news from the PHP community: the PHPDeveloper.org Newsletter.

The goal, at least for the initial version of the newsletter, is to provide links to all of the stories that have been posted during the week delivered directly to your inbox. Don't worry, neither the RSS feed or our Twitter account are going away - this is just an additional something to make getting the news you want even easier.

Sign up for the newsletter and you'll receive a weekly digest of all of the news posted during the week right here on PHPDeveloper.org.

On the php.internals mailing list Zeev Suraski, one of the developers behind the Zend Engine powering the PHP language, posted some thoughts about PHP 8, the next major jump for the language.

As I mentioned a few days ago I intended to send it slightly later - but as Nikita brought up the topic of PHP 8, this is probably as good a time as any to start the discussion.

The goal of this email isn't to discuss in detail each and every topic that's mentioned, but rather to establish whether we want to move to focus on PHP 8 as we go beyond PHP 7.3, based on some of the research projects and PoCs we've been working on.

He then lists out some of the places he thinks should be included in the next major version of PHP including:

• Just-in-time compilation
• Better support [for] long-running, async-based, microservices-focused execution model
• Preloading support.

He notes that the list he presented is by no means complete and not a decree of what should come but suggestions of where he sees the language could dramatically improve. The post has already gathered a large number of replies from people all over in the PHP community sharing their own ideas and responding to the ones Zeev presented in his original message.

Freek Van der Herten has a new post to his site sharing a resource you can use to more easily keep up with PHP internals and RFCs - the externals.io service.

When features get added to PHP there’s a lot of discussion first about the new functionality. This is done on the so-called internals mailing list. You can try to follow the discussions via a rather ugly interface at http://news.php.net. The site looks like a very old school web email client where all conversations are just running through each other.

A couple of days ago Matthieu Napoli launched his new site externals.io. This site makes following internals a lot easier.

The externals.io site provides a clean interface to the discussions happening on the php.internals list, including nested threads and the ability to track unread messages. It definitely makes it simpler to keep track of the line of emails in a thread, but it's definitely read-only with no intent on being a full on mailing list replacement.

According to this new article on the Softpedia site, Debian and several other major Linux distributions will soon be making the move up to PHP 7 for their releases, the latest major version of the PHP language.

The Debian developers have publicly announced their plans to migrate all of the PHP 5 to the brand new and powerful PHP 7 release, as well as to change the PHP packaging to allow co-installable versions.

The announcement was made by Debian developer Ond?ej Surý a few couple of days ago on one of Debian Project's mailing lists, where he informs Debian devs about the changes made to the PHP packaging for the operating system, in the pkg-php packaging group.

In fact, PHP 7 has already made it to the unstable releases of the Debian linux distribution for those that would like to test things out. You can find out more of the specifics in this mailing list post on their implementation plans.

Whether you're an aspiring speaker or one that's presented many times, it can be difficult to keep track of which conferences have open Call for Papers and what they're offering to speakers who are selected. Cal Evans has started up a new project that provides a curated listing of conferences in the form of a mailing list to keep you up to date and informed - The CFP Report.

I want to talk about a new project I have called "The CFP Report" and invite you to join. [...] A few months ago, I was chatting with my good friend Brandon Savage when he posited an idea. "What if we setup a mailing list for people who wanted to know about open CFPs?"

[...] The more I thought about it, the more I kinda liked the idea. I did some research and yes, there are other good services that are doing similar things. However, I couldn’t find anything that would do the job I wanted done. Specifically, I wanted not only to know about CFPs, I wanted to know if they were CFPs to which I would want to submit.

He talks about his though processes for wanting to create the mailing list and what it provides. The list (or a "push notification service" as he calls it) is only delivered via email to those subscribed and covers not only PHP CFPs but also Python, Javascript and Ruby. The service is free and all it takes is a quick signup and you're good to go. If you've been interested in getting out and trying your hand speaking at a conference, this is the perfect way to keep up to date right in the same inbox you use every day.

Pascal Martin has posted his latest summary of the discussions happening on the php.internals mailing list for the month of October 2014.

809 messages have been exchanged in October 2014 on PHP’s internals@ mailing-list — a bit more than in September. [...] First of all, PHP 5.6 has entered its normal cycle of releases, with a first maintenance version at the beginning of the month.

He includes a graph of the (monthly) number of emails over the last year and how October fits in. Topics mentioned include:

• an RFC to remove deprecated functionality in PHP7
• the RFC for the PHP7 release timeline
• Flagging functions as deprecated in favor of variadic functions
• Getting the XML output of a phpdbg tool closer to the DBGp protocol
• an RFC for big integer support
• an proposal for allowing objects as hash keys

If you'd like to follow along with the discussions or are interested in getting an "inside look" at what's going on with the language, you can use either the web-based reader or subscribe to the mailing list.

Pascal Martin has posted his latest edition of the happenings on the PHP internals mailing list for the month of September. In this latest edition he covers some of the major topics discussed this past month including:

• the "Implicit isset() in Shorthand Ternary Operator" RFC (or, as it came to be known, the "Null Coalesce Operator" RFC)
• An RFC for a "loop + or control structure"
• an opinion to make PHP 7 transtyping operations more strict
• the RFC to "Remove alternative PHP tags"
• another RFC proposed to "Fix list() behavior inconsistency"

There's links to lots of other topics and various messages on the list including lots of other RFCs and plenty of discussion around them. Check out the full post for more great information and links around last month's php.internals happenings.

Phil Sturgeon shares some of his thoughts about the almost "fear of change" that the PHP project seems to have. He cites the example of the T_PAAMAYIM_NEKUDOTAYIM constant, one that can be confusing for those not familiar with it.

Pretending PHP is perfect would obviously be ridiculous - it has its problems - but a list of issues being compiled gives interested developers a great chance to fix things. One such resource is PHP Sadness brought to you by Eric Wastl, to document valid bugs and freaky shit that PHP does. Whether it be the chicken or the egg, these items are one by one being scratched off as active core-contributors make RFCs and fight the good fight to get them merged.

Sadly it is not always easy to clear these items, or add new features in general. As somebody who has followed internals (and been hearing tales of woe from others) for a while, I've seen so many conversations with truly bizarre, irrelevant and trolly responses coming back from everyone all the way up to Rasmus himself.

For his example, the T_PAAMAYIM_NEKUDOTAYIM token, he goes through some of the history of it and the suggestions it's had for change from various parts of the community. There was a suggestion it be renamed to something more clear but it turned into a "battle of epic proportions." He goes through some of the comments from this (and other) discussion around the token and the confusion it causes, providing some of his own opinions along the way. The post is a good read, especially if you're not involved in the PHP internals world. It gives you a glimpse into what can happen around such a simple suggestion.

In this new post to his blog Pádraic Brady has proposed a "combining of forces" in the PHP community centered around promoting best practices in the security of PHP applications.

Once you start to dig around PHP Security in earnest, you begin to notice trends and patterns in how programmers behave and accumulate knowledge. The most obvious feature of PHP culture is that we do not have an active “leadership” in security. There is no appeal to authority in PHP security debates, only personal opinions informed by a nebulous entity called “They”. There are individuals that I have learned to trust and that’s about as far as we can go. [...] In the PHP community, the Authorative Knowedge for PHP Security is derived from a concensus. A concensus based on published articles, the practices of libraries and frameworks, printed books, and the vague meandering thoughts of whoever you follow on Twitter. In other words, our current Authorative Knowledge is you.

He notes that this "everyman security expert" hasn't proven to be the best method for increasing the overall security awareness of PHP developers, so he's proposing something different: the "PHP Security Technical Group (SECTG)".

It’s a group of members who share a common interest in sharing information, performing research, publishing articles/newsletters, and generally taking advantage of resource pooling without giving up their individual interests – all towards accomplishing some common goal, i.e. creating or emphasising new Authorative Knowledge. The phrase “Unofficial” is implicit in the group name – this is not an official PHP entity.

If you're interesting in joining in on the cause, you can sign up for the mailing list and get more information as it comes.