gersbach.net    > Agence de Développement Drupal

mr.TeeCee posted a photo:

mr.TeeCee posted a photo:

Recently a client complained that their site has been suffering from slow downs that were not there before. Upon investigating the history of resource utilization, we found that memory usage has increased, and at the same time, the load average has increased as well. To cut a long story short, we found out that initially, the site had neither dblog nor syslog modules were enabled, and they were enabled before the issues started. They started when syslog was enabled.

read more

Recently a client complained that their site has been suffering from slow downs that were not there before. Upon investigating the history of resource utilization, we found that memory usage has increased, and at the same time, the load average has increased as well. To cut a long story short, we found out that initially, the site had neither dblog nor syslog modules were enabled, and they were enabled before the issues started. They started when syslog was enabled.

read more

An interdiff-friendly workflow for revising core patches

1. Always pull the latest changes.
   git checkout 8.x
   git pull origin 8.x

2. Create a local branch for the previous patch.
   git checkout -b old_patch

3. Apply and commit that patch.
   git apply -v old.patch
   git status
   git add patched_file_1 patched_file_2
   git commit -m "Old patch."

4. Create a new local branch and make your changes.
   git checkout -b new_patch
   (make changes)
   git add changed_file
   git commit -m "New patch."

5. Create your new patch with a diff against the main branch.
   git diff 8.x > new.patch

6. Create your interdiff with a diff against the branch for the other patch.
   git diff old_patch > interdiff.txt

Tip: You can just use git add . instead of staging files individually if you configure your .gitignore to ignore patch files.

An interdiff-friendly workflow for revising core patches

1. Always pull the latest changes.
   git checkout 8.x
   git pull origin 8.x

2. Create a local branch for the previous patch.
   git checkout -b old_patch

3. Apply and commit that patch.
   git apply -v old.patch
   git status
   git add patched_file_1 patched_file_2
   git commit -m "Old patch."

4. Create a new local branch and make your changes.
   git checkout -b new_patch
   (make changes)
   git add changed_file
   git commit -m "New patch."

5. Create your new patch with a diff against the main branch.
   git diff 8.x > new.patch

6. Create your interdiff with a diff against the branch for the other patch.
   git diff old_patch > interdiff.txt

Tip: You can just use git add . instead of staging files individually if you configure your .gitignore to ignore patch files.

When you work with the great folks I do every day it comes as little surprise that when the stuff hits the fan and some site is in need of help there will be a legion of folks who jump into round-the-clock action to get things in a better place. While this could be a whole blog post about that alone it's not about that. Rather it's about one of those nagging little problems we came across while working on a site this Thanksgiving "holiday".

The problem is one that many have seen at one point or another:

[26-Nov-2011 22:35:17] PHP Notice:  unserialize() [<a href='function.unserialize'>function.unserialize</a>]: Error at offset 200 of 1100 bytes in /var/www/mysite/includes/bootstrap.inc on line 1104

In fact this problem pops up enough that it has its own page in the Drupal Handbook. The problem is pretty straightforward to understand. Some object was serialized for storage in the database and has become corrupted.

Finding the source of the problem, however, can be challenging. The Handbook page has several examples and more in the comments of some quick hacks that can be done to bootstrap.inc or can be employed with their own database connections to test these serialized values. There are times when neither hacking bootstrap.inc nor connecting to the db directly are practical. Indeed for many using Drush is a good way around both of these. I spent a couple minutes looking and didn't find any scripts out there yet so I cobbled together a quick Drush command to help out here.

read more

When you work with the great folks I do every day it comes as little surprise that when the stuff hits the fan and some site is in need of help there will be a legion of folks who jump into round-the-clock action to get things in a better place. While this could be a whole blog post about that alone it's not about that. Rather it's about one of those nagging little problems we came across while working on a site this Thanksgiving "holiday".

The problem is one that many have seen at one point or another:

[26-Nov-2011 22:35:17] PHP Notice:  unserialize() [<a href='function.unserialize'>function.unserialize</a>]: Error at offset 200 of 1100 bytes in /var/www/mysite/includes/bootstrap.inc on line 1104

In fact this problem pops up enough that it has its own page in the Drupal Handbook. The problem is pretty straightforward to understand. Some object was serialized for storage in the database and has become corrupted.

Finding the source of the problem, however, can be challenging. The Handbook page has several examples and more in the comments of some quick hacks that can be done to bootstrap.inc or can be employed with their own database connections to test these serialized values. There are times when neither hacking bootstrap.inc nor connecting to the db directly are practical. Indeed for many using Drush is a good way around both of these. I spent a couple minutes looking and didn't find any scripts out there yet so I cobbled together a quick Drush command to help out here.

read more

mr.TeeCee posted a photo:

mr.TeeCee posted a photo:

mr.TeeCee posted a photo:

mr.TeeCee posted a photo:

mr.TeeCee posted a photo:

mr.TeeCee posted a photo:

mr.TeeCee posted a photo: