Skip to content

Problems and Solutions

Catalog Rules are not being applied after night

There is a problem where catalog pricing rules are being dropped overnight. Here is the list of people discussing about it.

And the solution is this extension Chuvisco_CatalogRuleFix

Change page title in layout

The specific page title can be changed in the page's xml layout.

<reference name="head">
    <action method="setTitle">
        <title>Insert Your Title Here</title>
    </action>
</reference>

Add custom column to customer

This goes through the process of adding an IP column to the customer table.

The account controller override can be taken out and it can be replaced by an observer which logs the IP every time the customer logs in,

public function customerLogin($observer)
{
    $customer = $observer->getCustomer();

    $ip = Mage::app()->getRequest()->getServer('HTTP_X_FORWARDED_FOR');

    $customer['customer_ip_address'] = $ip;

    $customer->save();
}

Double model rewrite

There isn’t an easy way around extension conflicts. You could argue that better programming will work – e.g. by using Observers, taking advantage of source and backend models, writing your own MVC to sit alongside core Magento, etc. But my experience has shown that there are scenarios where you just need a re-write, especially where you are directly manipulating core functionality. Read more

Scenario: Trying to rewrite the Sitemap core magento model while it is already rewritten by another module(let's call it Module A).

Module A config.xml

<!--add comment to point out the rewrite has been modified/moved-->
<global>
  <models>
    <!--<sitemap>-->
        <!--<rewrite>-->
            <!--<sitemap>Company_ModuleA_Model_Sitemap</sitemap>-->
        <!--</rewrite>-->
    <!--</sitemap>-->
  </models>
</global>

Add the re-write to your module's config.xml

<global>
    <models>
        <sitemap>
            <rewrite>
                <sitemap>EdmondsCommerce_CategorySitemap_Model_Sitemap</sitemap>
            </rewrite>
        </sitemap>
    </models>
</global>

Add the depends tag in your module's xml reg file (eg public/app/etc/modules/EdmondsCommerce_CategorySitemap.xml)

<config>
    <modules>
        <EdmondsCommerce_CategorySitemap>
            <active>true</active>
            <codePool>local</codePool>
            <depends>
                <Company_ModuleA />
            </depends>
        </EdmondsCommerce_CategorySitemap>
    </modules>
</config>

Create your class EdmondsCommerce_CategorySitemap_Model_Sitemap that will extend the ModuleA class

class EdmondsCommerce_CategorySitemap_Model_Sitemap extends Company_ModuleA_Model_Sitemap {
    //insert override code here
}

How to debug a broken patch

  1. Diagnose the problem
  2. Google the path common problems
  3. Get patch file
  4. Check if all the patch changes/files exist
  5. Run patch file with -R example:
    sh PATCH_SUPEE-10888_CE_v1.9.3.7_v1-2018-09-19-02-59-39.sh -R
  6. Check if anything fails
  7. Get missing files until it is not failing
  8. Run revert patch file again
  9. Re-apply the patch
  10. Run magerun sys:setup:run
  11. Check scrips versions magerun sys:setup:compare-versions
  12. Test site make sure everything is ok

Invalid form key when saving stuff

There were two individual issues that were reported. First was that when saving certain cms blocks, magento would not save the changes and throw an "Invalid Form Key" error. The second issues was that when trying to import a price list, magento would say that the file is not uploaded because it is invalid. See screenshots below.

"Invalid form key" error

admin_invalid_form_key_shot

"File was not uploaded" error

file_not_up_shot

Beginning of debugging (assuming all steps will fail)

  1. Try to replicate in dev LXC
  2. Ask the client for more details (in this case, screen recordings were requested)
  3. Replicate the exact steps as the client in dev LXC
  4. Get same database as the client (preferably the dev live site and nto the actual live site)
  5. If the problem can be replicated, then XDebug the code and see where the faulty DB entry is
  6. If the dev environment is still not replicating the problem, use the dev site
  7. Find where the actual error is coming from
  8. Use var_dump($_POST); die(); before the code throws the error.
  9. Check if the post contains the "form_key" parameter
  10. In this particular case the post was completely empty on the slightly larger saved CMS blocks.
  11. This was caused by the server settings that strip post request above a certain threshold.