In this article, I'm going to introduce you a deployment tool called Deployer. I like to use it because it is written in PHP, is easy to set up, and has many handy features to integrate the deployment process into your team's workflow.
The TutsPlus.com site has posted the next part of their "Build Your Startup with PHP" series today. This time they show you how to make it even easier for the users of your site to sign up using OAuth and third-party authentication.
In this tutorial, I'll guide you through implementing OAuth integration with common social networks to make signing up and repeated usage easier and more efficient. I'll explore Facebook, Google, Twitter and LinkedIn, the networks I see as being most appropriate to Meeting Planner's target users.
The tutorial makes use of the Yii framework's own AuthClient functionality to make the actual requests to the 3rd party services. They help you get it installed via Composer and the configuration changes you'll need to make for it to be available and functional.
The tutorial then shows how to create developer applications on a few different services: Twitter, Facebook, Google and LinkedIn. They help you update your configuration with the secret keys for each and create a new database update for storing the 3rd party identifiers when the connection is made. Finally they hook it into the user profile and the login page for use by your users.
The SitePoint PHP blog there's a tutorial posted showing you how to integrate your application with Bugsnag, the "last error monitor you'll need". Bugsnag is an external service that provides you more insight into the errors in your application and statistics around them.
The pursuit of building an error-free application continues. But in the meanwhile, we need to monitor our application's errors and take action quickly. Many companies have tried to solve this problem, and one of the best on the market right now is Bugsnag. [...] In this article, we're going to discover Bugsnag and integrate it into an existing Laravel application. You can clone the demo app from Github to follow along.
The article walks you through the setup of the demo application (cloned from GitHub) and the creation of a Bugsnag account with a 30 day free trial. It then shows how to integrate the PHP notifier package into your application, though the sample application is Laravel-based so they show how to use this package in the examples. From there they show how to provide your credentials, set up the environment for the app (ex: production, development, etc) and methods for sending various messages types and content over to the service. The post then looks at the Bugsnag dashboard, giving a brief overview of how it looks and what features it includes.
In the first installment of this series we started our journey towards creating some simple but powerful functionality. The goal we set was to have the possibility to load a form on each node page and to be able to choose which form type should be used on the different node bundles. [...] It follows to see how we can configure the core node types to use one of the plugins defined on the site and how to render the relevant form when viewing the node. But first, in order to have something to work with, let's create our first ReusableForm plugin that uses a very simple form.
He starts back in with the creation of a first simple plugin to handle the form created in the previous part of the series, assigning the form to it via annotations. He then configures the node entities to be able to use the plugin via the services YAML configuration file. He then updates the .module with a function for altering node details and an entity builder. He updates the schema definition to be able to show the form and, finally, render the form out to the view with the assigned node entity types.
In this new post to his site, Cal Evans shares a handy tip for those using non-Composer libraries in a Composer-friendly project - using classmaps to bridge the gaps.
A problem I ran into when starting this project is that the official MailChimp API wrapper for PHP is NOT a Composer package. Thankfully, the wizards behind Composer have thought this through. To facilitate using non-Composer packages in composer projects, all I had to do is add one line to my "autoload" section of my project.
Using this "autoload" section, you can get Composer to add the path as a namespace to the class mapping. This lets it load them up in the same way i would any other PSR-0 formatted package. This will even work if you have libraries that aren't PSR-0 as it finds all of the files and pulls them into the map automatically.
Lukas Smith has a new post sharing what he sees as a growing trend in the development of PHP applications (a good thing) - the decoupled mindset more developers seem to follow and the use of tools like Composer that help to promote it.
As more and more projects adopt composer they will not only start using 3rd party code, they will also come to realize how easy it is for them to expose their code to 3rd parties. Obviously NIH syndrome will not be purged from the planet and maybe it should never get purged entirely anyway. But its already quite clear how much the landscape of the PHP community is changing with Symfony2, Doctrine, Zend Framework2, TYPO3 and many other projects having adopted composer.
He notes, however, that there still seem to be those clinging to "the old ways" and keeping things tightly bound to the technologies they're designed to work with. He's coming from the point of view of a Symfony2 user, so he gives the examples of some of the Bundles that are out there, reinventing functionality they could have pulled in from 3rd party libraries.
Jurian Sluiman has posted this guide to using other (3rd party) modules in your Zend Framework 2 applications with a few simple steps (code examples included).
The release of the first RC (release candidate) of Zend Framework 2 is getting close. One last beta (beta5) and then the RC will be announced! With the current pace of modules spawning on GitHub, I think it is a good idea to give some insights in how you can use 3rd party modules. In this blog post I will focus on MVC modules: modules with routes pointing to controllers and view scripts for rendering. Because using a 3rd party MVC module does not mean you are enforced to follow their routing scheme, use their view scripts or use the predefined forms, I will explain how you can modify those options to your needs.
He covers the three steps needed for integration - adding a new route to handle the requests to the module, adding a view script to handle its output and working with a Form instance to add a bit more handling.
Vance Lucas has tossed his hat into the ring in the debate about private versus protected scope in PHP projects with this new post to his blog.
The age old private vs protected debate has been re-ignited in the PHP community recently following the decision of Doctrine2 and Symfony2 to make all class methods private until there is a very clear and proven reason to change them to protected or public. The intention is a good one - to ensure they are providing a clear and stable API through intentional and known extension points that they can better test and support. [...] The problem is that this kind of thinking is a slippery slope that kills the spirit of programming.
He suggests that, by limiting the scoping down to private, you're taking away the very thing that gets most people excited about third-party tools - the extensibility. In his opinion, it sends a strong message to other developers that they're "not welcome" to make suggestions or updates to the application/tool.