Adrian's Blog

Tag: upgrade

  • After upgrade to Magento Downloader to 1.9.2 no upgrades are available

    Following an upgrade to Magento Downloader 1.9.2 I found that the Magento Connect (Downloader) “check for upgrades” returned nothing (quickly) and the mage upgrade community [package name] gave the following error:
    Error:
    upgrade: Package community/[package name] failed: Unknown cipher in list: TLSv1
    This is caused by the OpenSSL library being out of date, so either update it, or comment out line 377 in downloader/lib/Mage/HTTP/Client/Curl.php like so:
    //$this->curlOption(CURLOPT_SSL_CIPHER_LIST, ‘TLSv1’)

    Adendum: for 1.9.3.2 and 1.9.3.3 the fix is different:

    in /downloader/lib/Mage/HTTP/Client/Curl.php line 371

    change:
    protected function makeRequest($method, $uri, $params = array(), $isAuthorizationRequired = false, $https = true)

    to:
    protected function makeRequest($method, $uri, $params = array(), $isAuthorizationRequired = false, $https = false)

    (Changing the connection method to HTTP in Magento Connect Manager does NOT work.)
    If the downloader is itself updated, this “fix” will need to be repeated.

  • Magento 1.6 Customer Address Edit Error Invalid backend Model Specified

    Following an upgrade from Magento 1.5 to 1.6 the error:
    Invalid backend model specified: customer_entity/address_attribute_backend_region
    occurs during customer address edit or checkout address entry.
    This is because in the eav_attribute table, backend_model values are incorrect. Fix with the following SQL:

    UPDATE `eav_attribute` SET `backend_model` = 'customer/entity_address_attribute_backend_street' WHERE `attribute_code` ='street' LIMIT 1 ;
UPDATE `eav_attribute` SET `backend_model` = 'customer/entity_address_attribute_backend_region' WHERE `attribute_code` ='region' LIMIT 1 ;

  • Magento 1.3 to 1.5 upgrade notes

    The upgrade to 1.5 has a number of “gotchas” so while I am debugging the process on the test / staging instance, here are a few notes.

    Basic process

    Empty some or all of the log tables as they are potentially huge and are not needed:

    TRUNCATE `log_customer`;
TRUNCATE `log_quote`;
TRUNCATE `log_summary`;
TRUNCATE `log_url`;
TRUNCATE `log_url_info`;
TRUNCATE `log_visitor`;
TRUNCATE `log_visitor_info`;
TRUNCATE `log_visitor_online`;
TRUNCATE `report_viewed_product_index`;
TRUNCATE `report_compared_product_index;`
TRUNCATE `report_event`;
TRUNCATE `catalog_compare_item`;
TRUNCATE `index_event`;

    Backup the 1.3 instance using Magento’s built in backup.

    Edit the resulting .sql file and uncomment the FOREIGN_KEY controls at the top and bottom of the file:

    SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;

    If the domain or subdomain is changing, do a search & replace e.g. replace www.myshop.com with test5.myshop.com

    Create the new database instance, and execute the SQL from the previous step. Make sure it doesn’t time out, last table created is normally “wishlist_item”

    Yoast Metarobots breaks product maintenance in Magento 1.4+, so remove relevant fields:

    DELETE FROM `core_resource` WHERE `core_resource`.`code` = 'metarobots_setup';
DELETE FROM `eav_attribute` WHERE `eav_attribute`.`attribute_code` = 'meta_robots';
update eav_entity_type set additional_attribute_table='catalog/eav_attribute',entity_attribute_collection='catalog/product_attribute_collection' where entity_type_id=4;

    Now FTP the Magento downloader.php onto the target site, check file permissions and execute it with http://test5.myshop.com/downloader.php

    Follow the setup process including specifying the correct database name, user and password.

    Use the same encryption key from the original site – find it in /app/etc/local.xml

    If there are problems with the setup not accepting the admin user / password combination, simply re-run the installer by pointing your web browser at http://test5.myshop.com

    Remember that the original admin user already exists in the database export, so create a temporary one and delete it later.

    Fixing problems

    Can’t access the admin site, gives 404 error

    The database import will have incorrectly sequenced the sites, so run the following:

    SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
UPDATE core_website SET website_id="0" WHERE core_website.code="admin" LIMIT 1;
UPDATE core_store SET store_id="0" WHERE core_store.code="admin" LIMIT 1;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;

    Admin site is “white” i.e. CSS not working and plain HTML is displayed

    Delete contents of /var/cache/

    “There are no products matching the selection” when browsing front end

    Wrong customer group ID for users that are no logged in. Execute the following SQL:

    SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
UPDATE `customer_group` SET `customer_group_id` = 0 WHERE `customer_group_code` LIKE 'NOT LOGGED IN';
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;

    No product images

    Check correct permissions and then copy the images directory structure from the source site eg:

    cp /httpdocs/media/catalog/* /subdomains/test5/httpdocs/media/catalog/

    Now login to admin site and run a  re-index on everything, and update all of the caches.

    Error File does not exist: … media/catalog/product/no_selection

    Review the System Configuration and under Catalogue / Catalogue / Product Image Placeholders and add the missing placeholders. Add back in the watermarks too in General / Design / Product Image Watermarks.

  • WordPress 2.7.1 auto upgrade fix

    I discovered last night that the auto-upgrade function to take WordPress 2.7 to 2.7.1 failed – or rather it sat at the “downloading wordpress-2.7.1.zip” message indefinitely.

    At the auto-upgrade is a new feature of 2.7, I had never been able to test this functionality, although I had high expectations of it since the plugin upgrade has worked so well.

    After searching the forums and Google for a while I found bassmadrigal’s solution – modify .htaccess for the WordPress installation in question and add:

    AddType x-mapp-php5 .php

    Works fine, and the auto upgrade of plugins stills works too.

    The science bit

    Using 1and1 as a host requires this directive in .htaccess as detailed in the WordPress codex. It forces the 1and1 server to parse .php files as php5 files (instead of, presumably, php4).

    I had this before my upgrade to 2.7 (OK, technically a re-installation) and unfortunately the baby got thrown out with the bathwater.