array_diff(array, string) does(n't) work as expected

This is an old problem, quite a few security researchers already wrote about. But repeating things, helps learning them (especially me).

In MageSetup we read posted agreements (terms and conditions) and compare them with all the agreements we expect.

This looks like that:

$requiredAgreements = $this->_getCustomerCreateAgreements();
$controller = $observer->getEvent()->getControllerAction();
$postedAgreements = array_keys($controller->getRequest()->getPost('agreement', array()));

if ($diff = array_diff($requiredAgreements, $postedAgreements)) {
    // ERROR

Today I discovered a nasty bug: if you submit no array for agreement, you end up with:

array_diff([1,2,3,4], null);

Which throws two warnings:

Warning: array_keys() expects parameter 1 to be array, string given
Warning: array_diff(): Argument #2 is not an array

If developer mode is on, the warning is transformed into an exception and thrown, which "solves" the problem. But if dev mode is off, array_keys returns null first, and then array_diff() does the same.

So we don't have the expected check against our $requiredAgreements.

Please make sure, you are handling arrays, before passing them into array_* functions!

Magento core_config_data not loaded in backend

Guest Author: Rico Neitzel,

I sometimes have the following strange behaviour in Magento:

Config not loaded in Backend

  1. I do have valid config entries in core_config_data Table
  2. The backend in System -> Config doesn't reflect these config values from the table

On further investigation I saw that this usually only applies to the General Tab and the General Section.

My finding was astonishing! There had been a core_config_data Entry with the following data:

ID scope scope_id path value
123 default 0 general NULL

How did that happen?

I'm pretty sure that I accidentally clicked the "Add new row" Button in my SQL-Tool. That prefilled the fields with its (in SQL defined) default values. The main issue here is the default value for the path field: general

What did it do?

When Magento loads the configuration and applies the database config values this NULL value for general will overwrite all general/* settings and so the backend cannot find anything although it's stored in the DB.

How to solve it?

Dead simple: Remove that broken general entry from the core_config_data table and you're fine :-)

Disabling block cache

You want to disable block cache?

You can do it in layout.xml, cms block/page layout update, etc.

<action method="setCacheLifetime"></action>

More about this in Fabrizio Branca's blog

Thanks to sr_aromicon for the link!

Review Magento Updates

This blogpost is of the kind: I don't want to forget that this exists, therefore I hope it helps you, but it's mine. :o)

Magento updates are pain, because of the damn fcking cockspl*t @copyright header.

Thanks to Franklin P Strube there is a solution for this:

  • Copy your new magento version over the old one.

  • Run the command:

      git diff -G '@copyright.*[Cc]opyright' --name-only | xargs -I {} sh -c 'FILE={} ; [ $(git diff -U0 -- $FILE | wc -l | tr -d " " | cut -f1-) -eq 7 ] && git add $FILE'

Then most of the files which contain the copyright header are staged. Unforunately when I'm reading the command correctly, the whole file is staged, not only the line. Maybe only the files are added where ONLY the copyright header is changed. Please try.

There is a second answer from Luke H which might help too. I don't understand a word of these commands, so no description.

YAMB: Creditmemo with shippingInclTax > 0 and shippingAmount = 0

I think I just found yet another Magento Bug (YAMB).

I'm working on credit memos and want to add tax to adjustments (I hope I'll write a blog post about this soon - please remind me if you are interested).

I had the problem, that in \Mage_Sales_Model_Order_Creditmemo_Total_Shipping::collect the shippingAmount was 0 (as expected) but the shippingIncludingTax is the complete shipping amount (and is printed on our credit memos).

The problem ends here right before the end of the method.


I think the bug is the following problem. In the beginning all shipping values are initialized with the values from the order:

$shipping               = $order->getShippingAmount();
$baseShipping           = $order->getBaseShippingAmount();
$shippingInclTax        = $order->getShippingInclTax();
$baseShippingInclTax    = $order->getBaseShippingInclTax();

Due to the fact, that we do it through the backend, the following comment helps us. In the beginning I ignored the comment, and assumed that the baseShippingAmount is 0 and therefore the if shouldn't be entered.

$isShippingInclTax = Mage::getSingleton('tax/config')->displaySalesShippingInclTax($order->getStoreId());

 * Check if shipping amount was specified (from invoice or another source).
 * Using has magic method to allow setting 0 as shipping amount.
if ($creditmemo->hasBaseShippingAmount()) {
    $baseShippingAmount = Mage::app()->getStore()->roundPrice($creditmemo->getBaseShippingAmount());
    if ($isShippingInclTax && $baseShippingInclTax != 0) {
        $part = $baseShippingAmount/$baseShippingInclTax;
        $shippingInclTax    = Mage::app()->getStore()->roundPrice($shippingInclTax*$part);
        $baseShippingInclTax= $baseShippingAmount;
        $baseShippingAmount = Mage::app()->getStore()->roundPrice($baseShipping*$part);

What happens here? We get the current setting for displaySalesShippingInclTax, which should be including tax (but was excluding tax in my case).

So, if the tax setting is "wrong" (excluding tax), we don't enter the if block.

If we enter it, the part of the shipping would be calculated which is refunded (0) and everything is updated. But when the if block is not entered, the shippingInclTax is not updated and therefore the value of shippingInclTax is not consistent with shippingAmount

Images is from Pixabay and CC0
Thanks to 777546-777546