ECS and KISS dockerization of WordPress (Part 2)

‘Two article ago’ I wrote about my initial experience with Docker and ECS, the container service, built on top of EC2, offered by Amazon. Here it is if you want to take a look.

Today I want to continue in that direction describing the configuration of containers (or better container) I choose to serve the application selected as guinea pig to try ECS. Just as a reminder, the app was an almost standard WordPress blog with a custom theme and a few plugins.

Continue reading “ECS and KISS dockerization of WordPress (Part 2)”

WordPress and OpsWorks, “Pride and Prejudice” (Part 4)

4th part of the serie titled “Wordpress and OpsWorks“ (here you can find the 1st, 2nd and 3rd part).

Despite the title, this time I’m not going to talk about an aspect of OpsWorks specifically related to WordPress, since I’ll be presenting a brute force way to modify the default attributes merging behavior of OpsWorks.

Continue reading “WordPress and OpsWorks, “Pride and Prejudice” (Part 4)”

Check PHP syntax error in PHP.

This sounds much like “Inception” right?

Well a week ago I had the need to implement a PHP syntax check in PHP, to be more precise inside a PrestaShop (PS) module.

After a little bit of “googling” I stumbled upon a StackOverflow comment showing the solution I needed. Actually I missed the original link so I’m posting this pearl as a “bump” just to help spread the solution. I don’t own any credits 😉

Continue reading “Check PHP syntax error in PHP.”

WordPress and OpsWorks, “Pride and Prejudice” (Part 3)

I know, this third part of the series regarding WordPress and OpsWorks comes a little bit late. 

Between this article and the previous one of the series I wrote a lot of other gems spanning many different topics.
But now I’m here to continue right from where I stopped 😉

Before we begin, here’s the first and the second article.

Now, just to wrap up, last time I tried to explain a quirk about the compilation and the convergence phase of a chef node.

To present it I relied on a recipe I wrote to “set up” the database during the deploy of a WP (WordPress) application.

Everyone accustomed with WP development knows that, due the characteristics of WP itself, it is very often difficult to keep everything updated and working as expected.

Many functionalities depend not only on the code but also on the state of the database where most of the configurations are stored. The problem with WP is that there isn’t a recognized and out-of-the-box standard that can be followed to handle the aformentioned database state.

No Rails-like migrations, sorry.

A simple (but bad) way to solve this problem is to push, together with the code, a dump of the database directly inside the repository of the project. In this way it’s state can also be tracked and most of all restored (imported) whenever needed.
Obviously this solution doesn’t fit the case in which there are sensitive information that can’t be simply shared between all the project contributors.

Anyway, assuming this is not the case, if you plan to deploy a WP project through OpsWorks you may end up with the need to automatically import a dump just during a deploy.

This is exactly the purpose of the recipe taken as an example in the last article of this series.

But hey, as L.T. says, “Talk is cheap. Show me the code”. So, here it is:

script 'load_database' do
  only_if { File.file?(db_path) and Chef::Log.info('Load PrestaShop database...') }
  interpreter 'bash'
  user 'root'
  code <<-MIKA
    mysql -h #{deploy['database']['host']} -u #{deploy['database']['username']} #{deploy['database']['password'].blank? ? '' : "-p#{deploy['database']['password']}"} #{deploy['database']['database']} < #{db_path};
  MIKA
end

What I do here is simply to rely on the script resource to invoke the mysql Command Line Interface (CLI) and tell it to import the dump located at the path stored inside the db_path variable inside the proper database.
This is done by relying on the bash interpreter and by using all the info that OpsWorks gives us through a JSON object (one per deployed application) embedded inside the deploy attribute of the JSON associated with the deploy event.

{
  "deploy" : {
    "app1" : {
      "database" : {
        "database" : "...",
        "host" : "...",
        "username" : "...",
        "password" : "...",
      }
    },
    "app2" : {
      ...
    },
    ...
  }
}

The overmentioned info are picked up by OpsWorks (and underline, Chef) right from the app configuration that can be accessed from the OpsWorks dashboard.

The complete list of the deploy attributes can be found right here.

As a side note and as already stated in the previous article, the import of the database gets triggered only if the the dump is actually present and if a proper flag (i.e. “import_database”) is present inside the overmentioned JSON.

Next time I will talk about…well…I don’t know! There are really many things to talk about OpsWorks (and WP) so just stay tuned! 😉

Cheers!

PayPal and the broken PrestaShop module [SOLVED] ;)

Perfection doesn’t exist but we can strive for it.

Refactoring activities can be considered as the embodiment of this striving. In the context of these activities code gets modified and revamped to properly respond to new and/or future possible features.

The results of this process are nothing more than software updates. 

But software updates aren’t always the outcome of the refactoring process: they are very often (mainly) released to fix bugs and security flaws that otherwise could lead to serious problems.

Sometimes software updates can also be disruptive and bring changes that can cause themselves breakages inside the applications where they are applied.

This is exactly what happened to us just a few days ago when we updated the PrestaShop (PS) Paypal module to address the SSL v3 protocol vulnerability named POODLE.

As a result we ended up with a broken checkout process and the following error:


Please try to contact the merchant:
PayPal response:
TIMESTAMP -> 2013-04-23T01:25:10Z
L_ERRORCODE0 -> 10472
L_SHORTMESSAGE0 -> Transaction refused because of an invalid argument. See additional error messages for details.
L_LONGMESSAGE0 -> CancelURL is invalid.
L_SEVERITYCODE0 -> Error

Here there is a thread on the official PS forum concerning the problem.

The important thing is that in this case the module wasn’t entirely to blame. 

Indeed the problem was connected to the missing update of the files overriding the module templates.

PS modules templates represents the “V” (i.e. View) in the MVC architectural pattern on which PS modules founds their own roots. These views can be customized by overriding them and put their override files inside the PS theme in use.

This grants a good level of customization but at the same time it also injects some consistent dependencies between the modules and the theme. This can lead to problems like the one over mentioned. 

In our case the breakage was related to the change of a variable name inside one of the module templates. This was in particular one of the views used in the context of the payment hook (i.e. express_checkout_payment.tpl.)

Without any apparent reason the module developers changed the smarty variable used inside the value of the input field express_checkout from $PayPal_current_shop_url to $PayPal_current_page.

In our case the variable we were using wasn’t correctly valued and so we ended up with the over mentioned breakage.

The key takeaways of this post are mainly two.

The first one is that the use of the MVC architectural pattern doesn’t automatically ensures a proper separation from the business logic (i.e. the main functionality) and the view layer. To achieve that the pattern must be correctly implemented.

The second one is directly bound to the first and could be summarized in:

always remember to check which layers gets updated when you release an update or when someone else does.

As always I hope this can help to solve the over mentioned problem.

🙂

Cheers!

error_log all the things! (in Prestashop)

William Edwards Deming once said: "You can’t manage what you can’t measure.“

I find this statement pretty similar to: "If I can’t var_dump I can’t fix”.

Actually this statement is just a bit stronger than Deming’s one but I find it true in most of the cases.

It doesn’t matter if code is properly written and TDD and/or BDD are actually used. When a program begins to work unexpectedly, one of the things that is usually done to shed some lights on the problem is to put some “log” directives here and there and look at the results.

This kind of debugging strategy, while being rather primitive, can be very useful in many contexts.

For example if you’re developing something with PrestaShop (PS) (so you’re writing PHP…) you may feel the need to log something inside the apache error log.

This can be easily accomplished by using the PHP function error_log.

But this function  accepts only strings, so in order to log a complex structure like an hash you should first convert it to a string using something like var_dump or print_r.

Sincerely I was expecting some kind of support from PS core functionality but unfortunately this wasn’t the case.

As a result I end up writing a bunch of lines of code to log whatever I need right inside the apache error log.

Here they are:


class Tools extends ToolsCore
{
  public static function console_log()
  {
    $args = func_get_args();
    $log = '';
    foreach ($args as $arg) {
      $log .= print_r($arg, true);
    }
    error_log($log);
  }
}

I simply added a public static function to the Tools class (by properly overriding it) that takes any number of arguments and builds a string by using the print_r function.

The string is eventually logged on the apache error log.

I hope this can be useful to the ones willing to go with the old style debugging 😛

Cheers!

Ruby, PHP and the Array Map method

Due to my work and my academia commitments I find myself very often switching from Ruby to PHP and back again. This is making me more and more accustomed to the substantial differences between these two languages.

Among these differences the handling of collections is perhaps one of the biggest I found till now.

For example in Ruby there is a module (i.e. an object) called Enumerable that exposes a lot of useful helpers and utilities to work with collections (i.e. objects).

One of these utilities is map. The concepts underlined are pretty much the same across languages and are summarized here.

While working on a collection of objects, in particular a Nokogiri::XML::NodeSet, I recently had the need to extend the map behavior to get a collection of non duplicated Nokogiri::XML::Node elements.

Continue reading “Ruby, PHP and the Array Map method”

Simple Git HTTP server

The other day I had to share a repo to a colleague without him having access to the online repo.

Conscious that git can serve repositories through HTTP I set myself to discover the simplest way to do it without a full blown git hosting app like GitLab or Gitorious.

At that point I took out my google-fu and came up with the following:

git update-server-info # this will prepare your repo to be served
ruby -run -ehttpd -- . -p 5000
git clone http://localhost:5000/.git repo_name

Now by just knowing your IP anyone will be able to clone that repo.

BONUS

If you’re a PHP nostalgic OSX 10.10 comes with the php command which is able to serve a directory and interpret any PHP file in it (like mod_php would):

git update-server-info # this will prepare your repo to be served
php -S 0.0.0.0:5000 -t .
git clone http://localhost:5000/.git repo_name

Stay tuned for more PHP and Ruby awesomeness!