Archive - PHP RSS Feed

PHP 1, Java 0: The method assertEquals(Object, Object) is ambiguous for the type

Th old Ashley would never say this, maybe I’ve been working with PHP too long, but seriously, I’m going to have to side with the dynamic language crowd on this one – I think I have been spending too much time developing with Magento!

After an Eclipse upgrade a whole raft of my unit tests started failing to compile with the error: The method assertEquals(Object, Object) is ambiguous for the type. What this means is I’m passing an int and and Integer into a method that has two different signatures: assertEquals(Object, Object) and assertEquals(int, int) both of which could be called, thanks to autoboxing.
Continue Reading…

Removing the Compare function in Magento, the easy way

I normally always want to remove the Compare/Add to Compare functionality from the Magento stores I create, and in the past have changed the template files as though the compare functionality is being hidden in the theme. In a lot of ways that’s probably a fairly reasonable way to disable it, but something seems clunky about going through a bunch of phtml files in Magento directories grep‘ing and replacing Add to Compare everywhere. I recently did it a different way, that although may be slightly less well separated from the core Magento functionality (in terms of keeping the changes at the UI layer) – I think it makes it clearer.

There are really only two three four (Thanks Matt and Paulo) steps to removing the compare functionality, and they’re all fairly easy, here’s how to do it:

Disable comparison functionality in Magento

I did this on the command line, but I’ll explain the commands for those of you stuck in cPanel/Plesk/GUI hell. These commands are all run from the root of your Magento store.

First create the local override directory:

mkdir -p app/code/local/Mage/Catalog/Helper/Product/

Making this local code directory that mirrors the core Mage folder structure will allow Magento to pick up your custom file. WHich we now make by copying the original from app/code/core/Mage/Catalog/Helper/Product/Compare.php and putting it in the new directory we made app/code/local/Mage/Catalog/Helper/Product/:

cp app/code/core/Mage/Catalog/Helper/Product/Compare.php app/code/local/Mage/Catalog/Helper/Product/

Now we just make one small change to the file, by basically telling this helper to never return a comparison URL, the front end will never show the add to compare links. The change is made in the getAddUrl() function.

 public function getAddUrl($product)
    {
        #return $this->_getUrl('catalog/product_compare/add', $this->_getUrlParams($product));
        # We disable compare functionality by commenting out the real return statement and returning false instead.
        # Returning a boolean from a function that should return a string, somewhere, a kitten dies.
        return false;
    }

Save the file and you’re done. Now when you refresh the product/category page (you disabled the Magento cache right?) then you’ll no longer see the ‘add to compare’ links by the add to cart buttons.

Remove the Compare sidebar element

There is also the matter of the sidebar element, here’s the easy way to get rid of that.

Edit your theme’s catalog.xml file which is found in the app/design/frontend/X/Y/layout/ directory, where X and Y are your theme and package, possibly just default and default.

Remove the part that looks like this within the first <default> element:

 <reference name="right">
            <block type="core/template" before="cart_sidebar" name="catalog.compare.sidebar" template="catalog/product/compare/sidebar.phtml"/>
            <block type="core/template" name="right.permanent.callout" template="callouts/right_col.phtml"/>
 </reference>

This has the nice side effect of removing the back to school specials block too, obviously if you are actually running a back to school special, then only remove this line from the <reference> element:

<block type="core/template" before="cart_sidebar" name="catalog.compare.sidebar" template="catalog/product/compare/sidebar.phtml"/>

Edit: Thanks to Matt for pointing this out.

To remove the compare sidebar from the My Account section of the Magento store edit the file: customer.xml inapp/design/frontend/X/Y/layout/. Find the section:

<customer_account>

And remove this line from it:

<block type="core/template" name="catalog.compare.sidebar" template="catalog/product/compare/sidebar.phtml"/>

Edit: And thanks to Paulo for pointing this out – the compare sidebar is also included in the reports.xml file, so remove it from there in the same way:

<default>
    <!-- Mage_Reports -->
    <reference name="right">
        <block type="reports/product_viewed" before="right.permanent.callout" name="right.reports.product.viewed" template="reports/product_viewed.phtml" />
        <block type="reports/product_compared" before="right.permanent.callout" name="right.reports.product.compared" template="reports/product_compared.phtml" />
    </reference>
</default>

The line to remove is:

<block type=”reports/product_compared” before=”right.permanent.callout” name=”right.reports.product.compared” template=”reports/product_compared.phtml” />

And that should be it, no more compare functionality. Maybe it’d be nice to make this into a Magento extension, so that it can be enabled and disabled on the admin interface. If there is enough interest in that, I’ll bundle up my code change, it’s really only one file, after all. If you’re after something like that – let me know.

Fixing Magento Login Problem after a Fresh Installation

This is just a quick little note to suggest two ways to solve the problem that you cannot log in to your Magento admin interface after a fresh install of Magento.

The Problem

The problem will manifest itself as a redirect back to the login screen, even though you typed the right username and password. If this problem is affecting you, you will be redirected back and see no error message. This indicates you have the right credentials, but the Magento Admin is just not letting you in. You can verify it by typing the wrong username and password, you’ll see you get redirected back and it shows an error message.

The problem occurs because the Magento backend tries to set a cookie on your browser, and then for some reason when you next make a request, the cookie is gone(or was never there). This makes Magento think you have never logged in, and of course it redirects you to the login screen. So the real guts of it is the missing cookie, we need to find out why it’s missing.

There are two three solutions (Update: now with bonus 3rd solution) I have come across that will solve this, there may be others too, so please feel free to post them below. Both of these solutions have been suggested in the comments of my post on Setting up Apache Virtual Hosting.

Solution 1: Domain Name with no dots

This is the most common solution, if you have set up Magento to run locally (on MAMP for example) then you may be accessing the Apache webserver using the localhost hostname. A security setting in browsers means that the cookie will not be set, though apparently in FF3 at least, this behavior is a bug?.

So simply stop using localhost, you can use your localhost interface (e.g. 127.0.0.1 or 127.0.1.1). To determine your localhost interface you can look at the contents of your hosts file:

# Look for the number to the left of localhost
cat /etc/hosts

or your interface configuration.

# Look for interface loX with the LOOPBACK flag (probably lo0)
ifconfig

Once you know which number to use, you can replace localhost with the number. If you have already installed Magento using localhost then it will keep writing out links to localhost, even after you have changed to using the IP address, you will need to change the base_url values in the core_config_data table, you can run a query like this to find the right config values to change:

SELECT * FROM core_config_data WHERE VALUE LIKE "%localhost%";

This should identfy two config values that will need to update with a query like:

UPDATE core_config_data SET VALUE="http://127.0.0.1/" WHERE path IN ('web/unsecure/base_url','web/secure/base_url') ;

I’m going to assume you know to put the right value into that query, and not use the example one I have provided!

After changing that value you should delete your var/cache contents, and then refresh the page. Now you should have Magento running on an IP address, not a hostname with no dots in it. Of course you could always set up a fake domain name like www.testing.com by using a Virtual Hosting setup like I describe in my post on how to configure a MAMP Virtual host.

Solution 2: Timezone differences between server and client

One other, less likely problem, is that the cookie is being set, but expiring immediately. To check this you can inspect the cookies your browser is holding, and check if there is one there from Magento. If there is then check both the timezone your magento installation is using , and the one you have set locally, perhaps your local time is not set properly?

Solution 3: Cookie domain does not match server domain

This caught me out when I was replicating a remote site on my local mac development environment. I thought it’d be worth adding this solution here, seeing as this post still seems to rank well for Magento install problems. I had changed the base URLs but had forgotten to check the core_config_data table for any other Magento configuration data that might have been interfering with cookies. The config path in question is: web/cookie/cookie_domain.

You can check the table with an SQL command like this – you should be on the look out for config values that have hard coded the old URL:

SELECT * FROM core_config_data WHERE VALUE LIKE "%domain.com%";
 
-- Be on the look out for something like this:
|       513 | DEFAULT |        0 | web/cookie/cookie_domain               | DOMAIN.com                                     |

And update it to an empty string (less secure) or the new actual domain (more secure) as shown below:

UPDATE core_config_data SET VALUE = "" WHERE config_id = 513;
-- or
UPDATE core_config_data SET VALUE = "domain.com" WHERE config_id = 513;

Hopefully one of these two three solutions will get you back on track and able to log in to your newly installed Magento. Feel free to post problems or suggest other solutions in the comments below. I’m always more than happy to update my posts with helpful tips from readers.

Magento Error: It is not safe to rely on the system’s timezone settings

Ok, that’s not a really good post title, because it’s actually a PHP error, nothing to do with Magento as such. You’ll only see it on certain systems when PHP is set to report warnings like this (E_STRICT). I’m bundling this into the Magento category because it happened to me when installing Magento on a reasonably simple Ubuntu 8.04. I thought it might be handy to quickly document the solution for other Ubuntu users.

The problem will look like this in Magento:

It is not safe to rely on the system's timezone settings error in Magento

It is not safe to rely on the system's timezone settings error in Magento

Which spews out a whole lot of stuff, the most important of which is the message ‘It is not safe to rely on the system’s timezone settings’ and later the suggested timezone, in my case ‘Pacific/Auckland’:

There has been an error processing your request.
Strict Notice: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Pacific/Auckland' for 'NZST/12.0/no DST' instead  in /var/www/magento/app/code/core/Mage/Core/Model/Locale.php on line 498
Trace:
#0 [internal function]: mageCoreErrorHandler(2048, 'date() [storeTimeStamp('1')
#3 /var/www/magento/app/code/core/Mage/Catalog/Model/Resource/Eav/Mysql4/Product/Collection.php(318): Mage_Catalog_Model_Resource_Eav_Mysql4_Product_Collection->_joinPriceRules()
#4 /var/www/magento/app/code/core/Mage/Eav/Model/Entity/Collection/Abstract.php(779): Mage_Catalog_Model_Resource_Eav_Mysql4_Product_Collection->_beforeLoad()
#5 /var/www/magento/app/code/core/Mage/Catalog/Block/Product/List.php(151): Mage_Eav_Model_Entity_Collection_Abstract->load()
#6 /var/www/magento/app/code/core/Mage/Core/Block/Abstract.php(642): Mage_Catalog_Block_Product_List->_beforeToHtml()

The fix is in your php.ini file for Apache. You’ll need to have the permissions required to edit the php.ini file, on Ubuntu that means you’ll probably need sudo access, or root access on systems where you actually log in as root. You can edit the file using this command:

sudo vi /etc/php5/apache2/php.ini

Or if you prefer a slightly less convoluted text editor (but much less powerful):

sudo gedit /etc/php5/apache2/php.ini

The change you need to make is to find the line like this:

; Defines the default timezone used by the date functions
; date.timezone =

To this:

; Defines the default timezone used by the date functions
date.timezone = "Pacific/Auckland"

Of course you may want your timezone, not mine, in which case you should substitute "Pacific/Auckland" for you timezone!

Hopefully that helps others who encounter this problem. The tricky thing is it won’t manifest itself on the CMS homepage, so you might do an install and think everything is fine, only to find that when you finally add categories and actually view one of them, Magento breaks (well… PHP does). So be wary.

How to Bulk Enable Products when Google Checkout is Disabled in Magento

Magento allows you to disable Google checkout functionality for each product. Under certain situations though (when upgrading from 1.2 to 1.3 for example), the state of your products eligibility for sale through Google Checkout changes.

If you find yourself unable to sell products through Google checkout you can easily enable Google Checkout for your products through the Magento admin interface. However if you have many hundreds or thousands of products going through each one is not an option.

Here is a solution that will allow you to set the state of all your products to enabled for Google Checkout, quickly and easily. Testing has been limited to my own development installation, so as always backup your data before running anything.

Continue Reading…

Page 2 of 3«123»