Magento sets the tax_class_id attribute on the product level, which would require me doing a batch update of the products, however I can’t set a filter to specific categories which puts me back to square one.

Below is a simple SQL query that will update all products to a Tax Class of None, based on a set of category ids I define.

WARNING: Always do a complete database backup before running SQL queries against your database

UPDATE catalog_product_entity_int cpei
SET cpei.value = 0
WHERE cpei.attribute_id = (SELECT attribute_id FROM eav_attribute WHERE attribute_code = 'tax_class_id')
AND cpei.value = 2
AND cpei.entity_id IN (
    SELECT product_id AS entity_id FROM catalog_category_product
    WHERE category_id IN (1,2,3,4,5,6,7,8,9)
  )

Be sure to replace this section

WHERE category_id IN (1,2,3,4,5,6,7,8,9)

You can also change the tax_class_id you set these products to by modifying this line:

SET cpei.value = 0

After applying the SQL query, be sure to update the Product Flat Data under System > Index Management, then refresh all of your Magento caches under System > Cache Management

When you create a redirect from within cPanel, a Mod Rewrite rule is written to the .htaccess file located in the document root of the domain the rule is for.

If you open the .htaccess file, you should see this at the very bottom (after creating the redirect in cPanel):

RewriteCond %{HTTP_HOST} ^www\.domain\.com$
RewriteRule ^(.*)$ "http\:\/\/domain\.com\/$1" [R=301,L]

There are two issues related to litespeed.

1. The Rewrite rule must be placed at the top of your .htaccess file (some rules set by Magento conflict with litespeed’s rule interpreter)
2. The Rewrite rule must be formatted correctly (remove the escaping backslashes from the RewriteRule).

Your update rule should look like this:

RewriteCond %{HTTP_HOST} ^www\.domain\.com$
RewriteRule ^(.*)$ "http://domain.com/$1" [R=301,L]

After making these changes and saving your .htaccess file, your Magento www URLs should now redirect to their respective non-www URL counterparts.

I looked into it, and discovered that Magneto was calling a reindexing process, which usually takes a bit of time to complete. You obviously don’t want to wait an eternity to move a single category, so you can simply do the following as a temporary way of disabling the reindexing when you move a category.

Disclaimer: This has been tested only on Magento 1.6.2

1. Open app/code/core/Mage/Catalog/Model/Category.php
2. Look for the following, around line 248:

Mage::getSingleton('index/indexer')->processEntityAction(
  $this, self::ENTITY, Mage_Index_Model_Event::TYPE_SAVE
);
Mage::app()->cleanCache(array(self::CACHE_TAG));

/*Mage::getSingleton('index/indexer')->processEntityAction(
  $this, self::ENTITY, Mage_Index_Model_Event::TYPE_SAVE
);
Mage::app()->cleanCache(array(self::CACHE_TAG));
*/

You can alternatively do this permanently by overriding the Category.php file by copying the file to app/code/local/Mage/Catalog/Model/Category.php and commenting out the code above.

Once you are done the sort order, you can apply the changes to the frontend by reindexing the catalog_flat_data Index, and clearing your Blocks HTML output caches.

Magento is a great platform, but sometimes I wonder why the developers make some of their decisions (like adding a resource intensive reindexing to a simple action like moving a category).

Magento’s error message wasn’t very helpful, so I dove into the Models & Controllers and found the cause was due to the $_POST data not being submitted in full; leaving off important data required for Magento to save the rule to the database.

To fix this, I had to modify the max_input_vars for PHP, which by default limits the variables passed through $_POST to 1000. Since I was saving close to 2500 tax rates to the rule, only half of those were being passed, and the tax rule id data at the end of the Magento object was being cut off.

The Fix:
1. Open your php.ini file (the location may vary for you)
2. Update (or add if it doesn’t exist) the following line:

max_input_vars 10000

The issue is related to a small oversight by Magento developers, in the core GoogleAnalytics extension included with Magento.

If you have any quotes in your Magento’s store name, the Tracking Code will fail.  This is due to the quotes not being escaped in the javascript for the Analytics code.

To fix this issue, do the following…

1. Copy app/code/core/GoogleAnalytics/Block/Ga.php
   to app/code/local/Mage/GoogleAnalytics/Block/Ga.php
2. Open app/code/local/Mage/GoogleAnalytics/Block/Ga.php
3. On Line 122, Find: Mage::app()->getStore()->getFrontendName()
4. Replace With: $this->jsQuoteEscape(Mage::app()->getStore()->getFrontendName())
5. Save the file and test.

This basically escapes any quotes that may be included in your Magento store name.

I found that disabling logging from the Magento admin does not stop Magento from writing to the log tables in the database. To tell Magento to completely stop, do the following.

1. Open your app/etc/local.xml file
2. Paste in the following, right before the </config> closing tag:

<frontend>
    <events>
        <controller_action_predispatch>
            <observers><log><type>disabled</type></log></observers>
        </controller_action_predispatch>
        <controller_action_postdispatch>
            <observers><log><type>disabled</type></log></observers>
        </controller_action_postdispatch>
        <customer_login>
            <observers><log><type>disabled</type></log></observers>
        </customer_login>
        <customer_logout>
            <observers><log><type>disabled</type></log></observers>
        </customer_logout>
        <sales_quote_save_after>
            <observers><log><type>disabled</type></log></observers>
        </sales_quote_save_after>
        <checkout_quote_destroy>
            <observers><log><type>disabled</type></log></observers>
        </checkout_quote_destroy>
    </events>
</frontend>

3. Save your local.xml file

4. Now to go System > Configuration > Advanced and set Mage_Log to Disable

5. Finally, flush your Magento caches under System > Cache Management

Magento should no longer write logs to these tables.

To clean out your existing log tables, just run the following SQL command against your Magento database.

WARNING: Once you truncate these tables, the log information will be permanently lost. If you have no need for this log data, then by all means get rid of it!

TRUNCATE log_customer;
TRUNCATE log_quote;
TRUNCATE log_summary;
TRUNCATE log_summary_type;
TRUNCATE log_url;
TRUNCATE log_url_info;
TRUNCATE log_visitor;
TRUNCATE log_visitor_info;
TRUNCATE log_visitor_online;
TRUNCATE report_event;

For Example: app/code/local/CompanyName/ModuleName/Block/Adminhtml/ModuleName/Edit/Tab/Form.php

Add the following code:

$dateFormatIso = Mage::app()->getLocale()->getDateTimeFormat(Mage_Core_Model_Locale::FORMAT_TYPE_SHORT);
$fieldset->addField('start_date', 'date', array(
  'name'   => 'start_date',
  'label'  => Mage::helper('events')->__('Start Date'),
  'title'  => Mage::helper('events')->__('Start Date'),
  'image'  => $this->getSkinUrl('images/grid-cal.gif'),
  'input_format' => $dateFormatIso,
  'format'       => $dateFormatIso,
  'time' => true
));

The key things to make it work are the “input_format”, “format”, and “time” parameters in the addField array. Setting the “time” variable to “true” makes the time input fields appear in the date selector pop-up.