Rasmus Lerdorf Talks PHP 5.6, 6.0 and Beyond

Rasmus Lerdorf likes to joke that he’s the most famous programmer from Greenland that we’re likely to meet this month.  Truth is, the creator of PHP is one of the great legends of open source.  The software he created is one of the most widely used technologies for server-side web programming. We were fortunate to catch up with Rasmus at the WePay office, listen to his talk on the present and future of PHP.

His presentation is available here.  It covers PHP 5.5, PHP 5.6 and web deployment.  Rasmus also responded to questions from the audience about PHP 6.0.

The hot topics were performance, security, web deployment, compatibility with different PHP versions, and his perspective on Facebook Hack.


Here’s a sample of the great discussion that Rasmus had with the audience.

Q: Tell us about the direction of PHP, in particular PHP 6.

Rasmus:  First, I want to emphasize that PHP is driven by the needs of developers.  People will present features, including test cases.  If it’s reasonable, then the feature will get into PHP.  It’s not about my wishlist. I don’t have a team of developers. This is a community of developers building PHP for other developers.

Q: But, if you did have a feature wish list, what would you wish for?

Rasmus: If I had a wishlist, I would probably wish to clean up the internal API. It’s gotten a bit nasty over the years. The other thing is of course, performance.  

Q: What about backward compatibility?  I’m worried that PHP might go down the path that Python went down with Python 3 not compatible with Python 2.

Rasmus: We’re not planning a Python type of break. Chances are that anything that breaks in PHP 6 will be features that resulted in pretty hard warnings in PHP 5, which means that it wasn’t in the best interest of the developer to do that in the first place. No drastic changes are planned in PHP 6.

Q: What’s your take on the static code analysis?

Rasmus: Etsy uses static analysis. I would love to see it. The community is hoping to get Facebook to release their static analysis system as a standalone tool. This type of tool would make it much easier to be compatible between PHP 5.x and PHP 6.

Q: Any thoughts on Facebook Hack?

Rasmus: Facebook has done some amazing things. That said, not all of their work is going to be applicable to the entire PHP community. If we’re going to put new features into PHP, it has to be something that is good for the developer, not a special case for a specific company.

WePay API Documentation Revamp

WePay’s API has always been designed with platforms in mind - marketplaces, crowdfunding sites and small business software providers. In January, with our new Series C funding, we doubled-down and focused solely on platforms and the API. Now our documentation more clearly reflects this focus as well and makes it even easier for platforms to integrate our API.

Step by Step Examples

We’ve provided step-by-step examples for our top platform types to quickly integrate based on their unique needs.

Each of these examples:

  • Explains the overall scenario use case

  • Gives code samples you can copy & paste

  • Gives both the Simple and Advanced integration options

Announcing Our New Merchant Portal User Interface

We’re pretty excited to share an upcoming change that helps our partners and their merchants view WePay account balances and notifications. The new Merchant Portal provides better visibility into a user’s cash flow. 

For the past few months, we’ve been asking our partners how we can make it even easier for you to do your business. We learned that their merchants want to see:

  • pending payments
  • next scheduled withdrawals
  • current balance
  • amounts subject to reserves, disputes or chargebacks

Update - Creating and Managing Accounts

We’re excited to announce some changes that make handling your customers’ WePay accounts even more seamless. As of today, it will be easier to provision WePay accounts for your users without exposing them to any WePay interfaces. We’re also going to start communicating a new level of per-account detail.

Both of the changes outlined below require you to use the latest version of the API. You can implement them whenever you like, and not all changes have to be implemented simultaneously. For more information about WePay’s versioning process, please explore our documentation.

Designing an iOS Payments SDK for Security

WePay iOS Server Calls

At WePay, we think about security as our most important product. Security isn’t a background concern - it’s the product that has to be absolutely, 100% solid before any other products can be shipped. That philosophy has guided us towards figuring out the right way to construct an iOS SDK for the WePay API

Since releasing the WePay API in 2011, we’ve received continual requests to make integrating the WePay API into a mobile application even easier. The WePay API has always been language agnostic - companies have baked it into their iOS apps for quite some time. Our foremost concern has been developing an iOS SDK that enforces security best practices.