Im Magento-Backend (1.4) gibt es keine Möglichkeit, einmal erstellte Rechnungen wieder zu löschen. Um eine einzelne Rechnung zu eliminieren, ist dieser MySQL-Query hilfreich:

delete from `sales_order_entity_datetime` where `entity_id`='$entityId' and `entity_type_id` IN (17,18,19);
delete from `sales_order_entity_decimal` where `entity_id`='$entityId' and `entity_type_id` IN (17,18,19);
delete from `sales_order_entity_int` where `entity_id`='$entityId' and `entity_type_id` IN (17,18,19);
delete from `sales_order_entity_text` where `entity_id`='$entityId' and `entity_type_id` IN (17,18,19);
delete from `sales_order_entity_varchar` where `entity_id`='$entityId' and `entity_type_id` IN (17,18,19);
delete from `sales_order_entity` where `parent_id`='$entityId' and `entity_type_id`='20';
delete from `sales_order_entity` where `entity_id`='$entityId' and `entity_type_id`='18';

Dahinter verbirgt sich folgende Logik:

"sales_order_entity_*":
delete from `$table` where `entity_id`='$entityId' and `entity_type_id` IN (17,18,19);

"sales_order_entity":
delete from `$table` where `parent_id`='$entityId' and `entity_type_id`='20';
delete from `$table` where `entity_id`='$entityId' and `entity_type_id`='18';

Popularity: 18% [?]

Leider gibt es in Magento keine Möglichkeit, einmal erstelle Orders wieder zu löschen. Was aus buchhalterischer Sicht durchaus sinnvoll sein mag, erweist sich in der Praxis oftmals als Stolperfalle. Denn insbesondere in der Entwicklungsphase eines eCommerce-Projekts kommt man um das testweise Anlegen von Bestellungen kaum herum, um die Abrechnungs- und Fulfillment-Funktionalität von Magento und eventuell zusätzlich installierter Extensions auf Herz und Nieren zu prüfen.

Diese Bestellungen und Rechnungen liegen, wenn sie erst einmal erstellt worden sind, in der Datenbank vor, obwohl sie nie für die weitere Bearbeitung vorgesehen waren. Das ist besonders ärgerlich bei Bestellungen, die nur testweise angelegt wurden, um zB die Funktionalität des Shops oder einzelner Extensions zu überprüfen. Werden diese Testorders zB versehentlich bei der Erfassung des Steueraufkommens im Zuge der Umsatzermittlung mitberücksichtigt, ist Ärger vorprogrammiert.

Derartige Testorders, aber natürlich auch alle übrigen Bestellungen und Rechnungen, können zwar nicht über das Magento-Backend direkt, wohl aber über einen SQL-Inject gelöscht werden.
Für Magento 1.4.1 sieht diese SQL-Anweisung wie folgt aus:

SET FOREIGN_KEY_CHECKS=0;

TRUNCATE `sales_order`;
TRUNCATE `sales_order_datetime`;
TRUNCATE `sales_order_decimal`;
TRUNCATE `sales_order_entity`;
TRUNCATE `sales_order_entity_datetime`;
TRUNCATE `sales_order_entity_decimal`;
TRUNCATE `sales_order_entity_int`;
TRUNCATE `sales_order_entity_text`;
TRUNCATE `sales_order_entity_varchar`;
TRUNCATE `sales_order_int`;
TRUNCATE `sales_order_text`;
TRUNCATE `sales_order_varchar`;
TRUNCATE `sales_flat_quote`;
TRUNCATE `sales_flat_quote_address`;
TRUNCATE `sales_flat_quote_address_item`;
TRUNCATE `sales_flat_quote_item`;
TRUNCATE `sales_flat_quote_item_option`;
TRUNCATE `sales_flat_order_item`;
TRUNCATE `sendfriend_log`;
TRUNCATE `tag`;
TRUNCATE `tag_relation`;
TRUNCATE `tag_summary`;
TRUNCATE `wishlist`;
TRUNCATE `log_quote`;
TRUNCATE `report_event`;

ALTER TABLE `sales_order` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_datetime` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_decimal` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_entity` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_entity_datetime` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_entity_decimal` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_entity_int` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_entity_text` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_entity_varchar` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_int` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_text` AUTO_INCREMENT=1;
ALTER TABLE `sales_order_varchar` AUTO_INCREMENT=1;
ALTER TABLE `sales_flat_quote` AUTO_INCREMENT=1;
ALTER TABLE `sales_flat_quote_address` AUTO_INCREMENT=1;
ALTER TABLE `sales_flat_quote_address_item` AUTO_INCREMENT=1;
ALTER TABLE `sales_flat_quote_item` AUTO_INCREMENT=1;
ALTER TABLE `sales_flat_quote_item_option` AUTO_INCREMENT=1;
ALTER TABLE `sales_flat_order_item` AUTO_INCREMENT=1;
ALTER TABLE `sendfriend_log` AUTO_INCREMENT=1;
ALTER TABLE `tag` AUTO_INCREMENT=1;
ALTER TABLE `tag_relation` AUTO_INCREMENT=1;
ALTER TABLE `tag_summary` AUTO_INCREMENT=1;
ALTER TABLE `wishlist` AUTO_INCREMENT=1;
ALTER TABLE `log_quote` AUTO_INCREMENT=1;
ALTER TABLE `report_event` AUTO_INCREMENT=1;

-- reset customers
TRUNCATE `customer_address_entity`;
TRUNCATE `customer_address_entity_datetime`;
TRUNCATE `customer_address_entity_decimal`;
TRUNCATE `customer_address_entity_int`;
TRUNCATE `customer_address_entity_text`;
TRUNCATE `customer_address_entity_varchar`;
TRUNCATE `customer_entity`;
TRUNCATE `customer_entity_datetime`;
TRUNCATE `customer_entity_decimal`;
TRUNCATE `customer_entity_int`;
TRUNCATE `customer_entity_text`;
TRUNCATE `customer_entity_varchar`;
TRUNCATE `log_customer`;
TRUNCATE `log_visitor`;
TRUNCATE `log_visitor_info`;

ALTER TABLE `customer_address_entity` AUTO_INCREMENT=1;
ALTER TABLE `customer_address_entity_datetime` AUTO_INCREMENT=1;
ALTER TABLE `customer_address_entity_decimal` AUTO_INCREMENT=1;
ALTER TABLE `customer_address_entity_int` AUTO_INCREMENT=1;
ALTER TABLE `customer_address_entity_text` AUTO_INCREMENT=1;
ALTER TABLE `customer_address_entity_varchar` AUTO_INCREMENT=1;
ALTER TABLE `customer_entity` AUTO_INCREMENT=1;
ALTER TABLE `customer_entity_datetime` AUTO_INCREMENT=1;
ALTER TABLE `customer_entity_decimal` AUTO_INCREMENT=1;
ALTER TABLE `customer_entity_int` AUTO_INCREMENT=1;
ALTER TABLE `customer_entity_text` AUTO_INCREMENT=1;
ALTER TABLE `customer_entity_varchar` AUTO_INCREMENT=1;
ALTER TABLE `log_customer` AUTO_INCREMENT=1;
ALTER TABLE `log_visitor` AUTO_INCREMENT=1;
ALTER TABLE `log_visitor_info` AUTO_INCREMENT=1;

-- Reset all ID counters
TRUNCATE `eav_entity_store`;
ALTER TABLE `eav_entity_store` AUTO_INCREMENT=1;

SET FOREIGN_KEY_CHECKS=1;

Popularity: 20% [?]

Problems with Product Visibility in Magento

When first setting up a Magento-eCommerce-site, almost everyone wonders why products are not being shown on the actual site, even though everything seems to be filled out correctly. In this little article, I’d like to explain how to make sure a product is shown on the site after it has been created via the Magento-backend.

Here goes a little checklist of what to do in order to have your products being shown in your Magento-eCommerce-Shop..

Checklist

• in Catalog/Manage Products : fil out all required fields in each tab and click “save and continue edit” when finished
• in Catalog/Manage Products/General : make sure “Status” is set to “Enabled”
• in Catalog/Manage Products/General : set “Visibility” to “Catalog”, “Search” or “Catalog, Search”
• in Catalog/Manage Products/Inventory : set “Qty” to a value greater than 0
• in Catalog/Manage Products/Inventory : set “Stock Availability” to “In Stock”
• in Catalog/Catgories : assign your product to at least one category (you might have to create one first)
• in CMS/Pages : select “Home Page”, then switch to the “Content”-tab and enter {{block type=”catalog/product_list” category_id=”21″ template=”catalog/product/list.phtml”}} into the large content-textarea (you might have to adjust the category_id if your newly created category_id differs from the one in this example.

Popularity: 35% [?]

Customizing Magento by overwriting core-classes

There are several possibilities of overwriting single magento-methods or whole classes. Of course you could be just altering the core-classes themselves in a quick and dirty approach. however, you should avoid this practice under all circumstances, because it corrupts the update-facilities of your eCommerce-site. Once you are upgrading your magento-copy to a newer version, all your changes would get lost.

Luckily, overwriting native magento-classes is pretty straight-forward, and therefore there is no reason not to do it the right way.

In this example, we are overwriting the core method of the block-class “Onepage_Billing” of the Mage_Checkout-core module to add another default address. This is just an example to show how you actually add new functionality by inheriting from a Magento-coreclass and overwriting particular methods.

Extend Magento Core-Class

app/code/local/Test/Checkout/Block/Onepage/Billing.php

First we derive from the class that we actually want to overrule. In our example, we are simply overwriting the core Onepage_Billing-class of the Mage_Checkout-core-module with an inherited class called

Test_Checkout_Block_Onepage_Billing

, which declares and therfore overrules the method

getAddressesHtmlSelect

. In this method we can add and/or alter all the functionality that we actually need.

<?php
class Test_Checkout_Block_Onepage_Billing extends Mage_Checkout_Block_Onepage_Billing
{
    public function getAddressesHtmlSelect($type)
    {
        if ($this->isCustomerLoggedIn()) {
            $options = array();
            foreach ($this->getCustomer()->getAddresses() as $address) {
                $options[] = array(
                    'value' => $address->getId(),
                    'label' => $address->format('oneline')
                );
            }

            $addressId = $this->getAddress()->getCustomerAddressId();
            if (empty($addressId)) {
                if ($type=='billing') {
                    $address = $this->getCustomer()->getPrimaryBillingAddress();
                } else {
                    $address = $this->getCustomer()->getPrimaryShippingAddress();
                }
                if ($address) {
                    $addressId = $address->getId();
                }
            }

            $select = $this->getLayout()->createBlock('core/html_select')
                ->setName($type.'_address_id')
                ->setId($type.'-address-select')
                ->setClass('address-select')
                ->setExtraParams('onchange="'.$type.'.newAddress(!this.value)"')
                ->setValue($addressId)
                ->setOptions($options);

            return $select->getHtml();
        }
        return '';
    }
}

Activate Module

app/etc/modules/Test_All.xml

Now it’s time to tell Magento that there is a module (in our example we have named it “Test”) which adds customized functionality to the Magento-core-functionality.

<?xml version="1.0"?>
<config>
    <!-- Please add items in alphabetic order. -->
    <modules>
        <Test_Checkout>
            <active>true</active>
            <codePool>local</codePool>
        </Test_Checkout>
     </modules>
</config>

Actual Overwrite

app/code/local/Test/Checkout/etc/config.xml

Now this is where the Magento-rewrite-magic pops in. By providing a rewrite-directive in the Test_Checkout-config.xml, Magento’s default behaviour can be overruled for certain pages, and we can make sure that our derived class is being loaded instead of the core Checkout-module from Magento.

<?xml version="1.0"?>
<config>
    <modules>
         <Test_Checkout>
            <version>0.1.0</version>
        </Test_Checkout>
    </modules>
    <global>
	    <blocks>
		    <checkout>
		        <rewrite>
		            <onepage_billing>Test_Checkout_Block_Onepage_Billing</onepage_billing>
		        </rewrite>
		    </checkout>
		</blocks>
   </global>
</config>

Clear Cache

Whenever we are changing Magento-settings by adding or modifying the underlying xml-configuration-files, we have to empty the cache (residing at app/var/cache) in order to have the changes come into effect. So before going wild because your changes don’t show, rather empty Magento’s file-cache.

Popularity: 83% [?]