Hasin HayderHow to enable some useful text formatting options in TinyMCE in WordPress (2.10.2014, 09:17 UTC)
Link
Hasin HayderFind n number of posts randomly from a group of categories in WordPress (1.10.2014, 16:26 UTC)
Link
SitePoint PHPUsing the Google Analytics API with PHP: Logging In (1.10.2014, 16:00 UTC)

In this series, we’re going to see how we can use the Google Analytics API to interact with our Google Analytics data via PHP.

Requirements

To be able to follow along, you need to have a Google Analytics account which you can get from the Google Analytics page.

You also need to be familiar with the basic usage of the Google Analytics dashboard.

Google Analytics Dashboard

What are we going to build?

In this article we’re going to build an app that looks like Google Analytics Explorer, but to make it short, we’re going to limit the functionality and discuss how we can extend our demo.

Continue reading %Using the Google Analytics API with PHP: Logging In%

Link
Cal EvansInterview with Yitzchok Willroth (1.10.2014, 05:00 UTC) Link
Matthias NobackAnnouncements after a year with "A Year With Symfony" (30.9.2014, 22:00 UTC)

As a follow-up on a previous article I have some announcements to make.

Feedback

A wonderful number of 67 of you have provided very valuable feedback about "A Year With Symfony" - you sure wrote some nice things about my book! Just a small selection of highlights:

Reading "A Year With Symfony" helped to clarify and validate the ideas and structures that I had been developing with my team, along with explaining some of the internals of Symfony that the documentation did not.

There is lots of practical advice, solutions to common problems and general best-practice information contained and anyone who uses Symfony absolutely MUST read this book - a genuine godsend!

— Matthew Davis

This book is well written and has filed in many of the gaps I had in my understanding of how Symfony works at its core. I finally understand how to use the dependency injection component correctly and why configuring controllers and commands as services can be an excellent idea. The chapters on project and bundle organization have caused me to change the way I code to make it more understandable, more flexible, and more resilient. I'm going to be reading this book again because there is so much excellent information in this book that I'm certain I missed wrote a bit.

— Joshua Smith

"A Year with Symfony" was a really great and smooth read and it's the perfect book as a follow up to the official "The Symfony Book" with a great collection of best practices for building maintainable web applications with Symfony2.

— Dominik Liebler

Prizes!

Notebook

Those of you who submitted the form automatically took part in a raffle of some book-related things like free printed and digital copies of the book, as well as a special edition notebook. All participants have been notified of the outcome already. The winners are:

  • 5 printed copies: Lukasz, Nikolai Zujev, pinouf and Liviu Mirea
  • 10 digital copies: Sadok Ferjani and Heiko Krebs
  • 5 notebooks: Erik van Wingerden and Peter Nijssen

Rewriting an existing chapter

As I told you, I'm planning to rewrite the "Project structure" chapter of my book. It will be replaced entirely by something more up-to-date, corresponding to my own current practices. Some of the things you may expect the new chapter to be about: hexagonal architecture, commands and command handlers and events and event handlers.

Writing a new chapter

I also asked you: what would you like me to write about, if I were to publish a new chapter? This is the list of potential subjects I provided and the number of times you voted for them:

Subject Votes
Performance optimization 41
Testing 41
Deployment 35
Forms 29

For completeness sake, this is a list of other subjects that were mentioned: REST API, domain separation, BDD, black-box testing and white-box testing, writing APIs, Silex, Doctrine2 best practices (but each of them not more than once).

It is clear that most people find all of the potential subjects quite interesting, even though "Performance optimization" and "Testing" are absolute winners. On both subjects I might have some useful thoughts to share, but I've already written a blog post series about testing for PHP. Also, the subject of "Performance optimization" has some very Symfony-specific aspects to it. So I have decided that the second bonus chapter will be about:

Performance optimization!

However, first I'm going to finish my second book Principles of PHP Package Design, since that one has been begging for my attention the last couple of months. So expect to hear more about my plans for "A Year With Symfony" in 2015.

General discount

Let's continue the party a little longer, by applying a general discount of 20% to "A Year With Symfony". You don't need a special discount code or anything. Just buy the book via Leanpub.

Conclusion

I've got nothing more to say than: thank you again, for your overwhelming response and your continuous support of my book writing and blog posting efforts.

Link
Hasin HayderPassing data from PHP to the enqueued scripts in WordPress (30.9.2014, 17:16 UTC)
Link
Paul M. JonesAction-Domain-Responder and the “Domain Payload” Pattern (30.9.2014, 17:16 UTC)

tl;dr: Instead of inspecting a Domain result to determine how to present it, consider using a Domain Payload Object to wrap the results of Domain interaction and simulataneously indicate the status of the attempted interaction. The Domain already knows what the results mean; let it provide that information explicitly instead of attempting to re-discover it at presentation time.

In Action-Domain-Responder the Action passes input to the Domain layer, which then returns some data for the Action to pass to the Responder. In simple scenarios, it might be enough for the Responder to inspect the data to determine how it should present that data. In more complex scenarios, though, it would make more sense for the Domain to pass back the data in a way that indicates the status of the data. Instead of the Responder inspecting the Domain results, the Domain should tell us what kind of results they are.

For example, let’s look at an example of some older code to update a Blog post. This is MVC-ish code, not ADR code; we’ll refactor along the way.

<?php
class BlogController
{
    // POST /blog/{id}
    public function update($id)
    {
        $blog = $this->model->fetch($id);
        if (! $blog) {
            // 404 Not Found
            // (no blog entry with that ID)
            $this->response->status->set(404);
            $this->view->setData(array('id' => $id));
            $content = $this->view->render('not-found');
            $this->response->body->setContent($content);
            return;
        }

        $data = $this->request->post->get('blog');
        if (! $blog->update($data)) {
            // update failure, but why?
            if (! $blog->isValid()) {
                // 422 Unprocessable Entity
                // (not valid)
                $this->response->status->set(422);
                $this->view->setData(array('blog' => $blog));
                $content = $this->view->render('update');
                $this->response->body->setContent($content);
                return;
            } else {
                // 500 Server Error
                // (i.e., valid data, but update failed for some other reason)
                $this->response->status->set(500);
                return;
            }
        }

        // 200 OK
        // (i.e., the update worked)
        $this->response->status->set(200);
        $this->view->setData(array('blog' => $blog));
        $content = $this->view->render('update');
        $this->response->body->setContent($content);
    }
}
?>

We can see that there is some amount of model work going on here (look for a blog post, attempt to update it if it exists, check for error conditions on the update attempt). There is also some amount of presentation work going on; remember, the view is not the template – the view is the response. So, even though the view templates are separated, the HTTP status codes are also part of the presentation, meaning that there is an insuffcient level of separation of concerns.

In converting this to Action-Domain-Responder, we can pretty easily extract the model work to a Domain, and the presentation work to a Responder, resulting in something like the following. (Note that the Domain layer now adds values to the returned $blog entity to indicate different failure states.)

<?php
class BlogUpdateAction
{
    // POST /blog/{id}
    public function __invoke($id)
    {
        $data = $this->request->post->get('blog');
        $blog = $this->domain->update($id, $data);
        $this->responder->setData('id' => $id, 'blog' => $blog);
        $this->responder->__invoke();
    }
}

class BlogUpdateResponder
{
    public function __invoke()
    {
        if (! $this->data->blog) {
            // 404 Not Found
            // (no blog entry with that ID)
            $this->response->setStatus(404);
            $this->view->setData($this->data);
            $content = $this->view->render('not-found');
            $this->response->body->setContent($content);
            return;
        }

        if ($this->data->blog->updateFailed()) {
            // 500 Server Error
            // (i.e., valid data, but update failed for some other reason)
            $this->response->status->set(500);
            return;
        }

        if (! $this->data->blog->isValid()) {
            // 422 Unprocessable Entity
            // (invalid data submitted)
            $this->response->setStatus(422);
            $this->view->setData($this->data);
            $content = $t

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

Link
SitePoint PHPInteractive PHP Debugging with PsySH (29.9.2014, 16:00 UTC)

It’s 1:00 a.m., the deadline for your web application’s delivery is in 8 hours… and it’s not working. As you try to figure out what’s going on, you fill your code with var_dump() and die() everywhere to see where the bug is…

You are annoyed. Every time you want to try out a return value or variable assignment, you have to change your source code, execute your application, and see the results… In the end, you are unsure of whether or not you’ve removed all those var_dumps from the code. Is this situation familiar to you?

PsySH to the rescue

PsySH is a Read-Eval-Print Loop (or REPL). You may have used a REPL before via your browser’s javascript console. If you have, you know that it possesses a lot of power and can be useful while debugging your JS code.

Talking about PHP, you might have used PHP’s interactive console (php -a) before. There, you can write some code and the console will execute it as soon as you press enter:

$ php -a
Interactive shell

php > $a = 'Hello world!';
php > echo $a;
Hello world!
php >         

Unfortunately, the interactive shell is not a REPL since it lacks the “P” (print). I had to execute an echo statement to see the contents of $a. In a true REPL, we would have seen it immediately after assigning the value to it.

Continue reading %Interactive PHP Debugging with PsySH%

Link
Piotr PasichRabbit behind the scenes (28.9.2014, 06:38 UTC)
rabbit

Queuing in the background – getting started with RabbitMQ message broker

In PHP business logic is usually put right in action’s method or just behind it. Hence, every little piece of delaying and long-running code will be processed with a request. The problem is almost undetectable if a user sends an e-mail but with more complex actions it may take a little bit longer than preferred.

An example with handling e-mails is the first to come to mind. But let’s imagine that an application needs to compress an image or to compress batch import images. It will take a way too much time until the page will return any response. Probably, most developers will create a simple “queue” table and use SELECT * FROM queue WHERE done = 0 query. Unfortunately, databases are not designed to handle huge traffic so this solution might work only in case of tiny transfer rate, where – to be honest – using queues is unnecessary. In any other situation it will only cause deadlock or stuck and lead to further problems related to traffic growth. Of course, it is possible to write a custom solution to queue the import bulk and render images one by one and call it in the background right after the request, but it is unreasonable effort considering availability of ready made products.

Besides, would custom made solutions be prepared for scalability, cloud systems or speed performance out of the box? I believe they might be, but certainly not in a couple of hours – after this time off the shelf solutions generally will be inefficient and poorly prepared for development and reusability in the future. Thus, we can claim that this method is not a perfect problem fixer, so we should find another way to cope with the queuing.

As you presume, there is an effective solution that mitigates the impact of above mentioned problem – usage of a ready made message broker. Basically, the message broker receives the message with a new database record with every request but it will not cause a deadlock, because the server asks the message broker for data only when has resources and capacity.

In this article I would like to make an attempt to present a solution to the very annoying everyday problem that probably many programmers came across in their organisations – deadlocks in databases caused by a vast number of requests in relatively short time. The main aim of this text is to introduce RabbitMQ, which I value as a very functional and practical message broker, to help you solve the queuing problems and decrease the amount of work you would otherwise have to spend on it.

Why do we need a message broker?

Queuing brokers are useful for several reasons. Firstly, a queue between an application and the web service will reduce coupling, because both need queue’s configuration parameters and its name. It is more likely and convenient to move one system to different server or environment than to move whole queue management system. Secondly, queues work as a buffer – if the main application receives a lot of requests coming in in a short time it certainly will get stuck. The accounting system is able to process them all anyway, but using brokers prevents deadlocks – the broker will handle all requests which cannot be processed on time by the main application. Moreover, queuing is a smart bridge between applications written in different technologies and languages. A software does not need to know anything about receiver, it only sends a message to broker which handles the reports and distributes them to external programs.

How to choose the perfect broker?

Likewise choosing a framework or even a programming language, a few tools purposed for queuing tasks in the background are available. Similarly, according to the t-shape principle (suggesting to gain a wide spectrum of skills with perfectly mastered one) you should have basic knowledge about most of the queuing tools but dig into only one. Each one is different and handles various problems and it is really important to be aware of pros and cons of every alternative.

Because of this great number of choices, to narrow users’ options there is a website http://queues.io/ that collects and compares queues libraries, provides short descriptions of advantages and weaknesses and as a result helps to select the right tool.

I advise to make the choice between one of these: RabbitMQ (http://www.rabbitmq.com), Gearman (http://gearman.org/), ActiveMQ (http://activemq.apache.org/), Apollo (http://activemq.apache.org/apollo/), laravel (

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

Link
SitePoint PHPA Year of SitePoint (27.9.2014, 18:00 UTC)

Today marks the one year anniversary of my editing job at SitePoint.

It sure went by fast - in fact, I was genuinely surprised when LinkedIn “likes” started popping up. In this short post, I’d like to take a moment to reflect on the past 365 days, and share with you what I’ve learned and how things changed.

Chaos in the Old World

When I first took the job and stepped into Tim’s shoes, I’m not going to lie - I was overwhelmed. With a big and chaotic author roster, I had very little time to get familiar with the writers, the approach to accepting drafts, the editing process and the aspect of communication with both HQ and the author pool.

Vagrant still not having been a tool as popular as it is and Docker basically not existing yet made things more difficult to test - every code sample came with its own prerequisites, and it was more work than my home Linux playbox could handle, sometimes reinstalling the PHP development environment several times per day. My machine looked messier every day.

Continue reading %A Year of SitePoint%

Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP