Archive for the ‘Uncategorized’ Category

Have you ever wanted to disable email sending on Magento so that you do not need to worry about accidentally sending emails out when you are testing your store. Well there is an easy way to do this.

Log into the admin of you store and go to: System -> Configuration -> System -> Mail Sending Settings -> Disable Email Communications

Here is a link to the Widgets Install zip.

This is just a quick How-to, I do not detail how to create a new widget.

All you need to do is add a gif with the correct file name to the following directory:
/skin/adminhtml/default/default/images/widget/

Now, to name the gif. In you widgets.xml file you set the widget “type”, which is the block class for the widget. Just replace the “/” slash with a double underscore and that is the file name. so if I had a widget with the type set to “custommodule/wigets_customwidget” I just create a gif with the name “custommodule__wigets_customwidget.gif”.

End result:
/skin/adminhtml/default/default/images/widget/custommodule__wigets_customwidget.gif

In most releases of magento the auth.net payment module has online refunds disabled by default. This post is not about how to enable online refunds for auth.net, but how to fix bug that I have hit after enabling online refunds.

If you just edit the Authorizenet Class and enable refunds and partial refunds, you may still hit some bugs. I recently found that partial refunds were being recorded by Magento corectly, but auth.net was actually refunding the entire order amount, not just the partial amount. This was because Magento was pulling the amount to refund from the payment object which in most cases will be the entire order total. Inorder to fix this I had to tell auth.net to use the refund amount from the credit memo request.

//In the refund method in /Paygate/model/Authorizenet.php we need to modify the x_amount in the request
//Notice the one line i added after the call to $this->_buildRequest
public function refund(Varien_Object $payment, $amount)
    {
        if ($payment->getRefundTransactionId() && $amount > 0) {
            $payment->setAnetTransType(self::REQUEST_TYPE_CREDIT);
            $request = $this->_buildRequest($payment);

            //added to get the proper amount to be refunded
            $request->setXAmount($amount,2);
            //END Custom

            $request->setXTransId($payment->getRefundTransactionId());

            /**
             * need to send last 4 digit credit card number to authorize.net
             * otherwise it will give an error
             */
            $request->setXCardNum($payment->getCcLast4());

            $result = $this->_postRequest($request);
            if ($result->getResponseCode()==self::RESPONSE_CODE_APPROVED) {
                $payment->setStatus(self::STATUS_SUCCESS);
                return $this;
            }
            Mage::throwException($this->_wrapGatewayError($result->getResponseReasonText()));
        }
        Mage::throwException(Mage::helper('paygate')->__('Error in refunding the payment.'));
    }

Now your online refunds will use the correct amount.

I recently decided to wipe my old windows xp laptop and install Windows 7 and a version of Ubuntu(backtrack 4r2). I ran into an issue after installing both OS’s. Grub was throwing an error 18. After quite a bit of digging here is what I found.

The version of Ubuntu I was installing used Grub Legacy not Grub2. Apparently this version of Grub has a limit of where it can find bootloaders. This means that the grub bootloader needs to exist early on the disk. Here is how I got things working.

I was using a 250GB HD and installed windows 7 first to a partion sized at 70Gigs. Then I installed Ubuntu to a partition(60 Gigs) directly after the Windows 7 partition. This is how I circumvented the Error Mentioned above. Now I have some unused disk space I can create extra NTFS of Linux partitions.

Hope this helps.

Download the Zip File Below and you will be on your way to allowing payment methods for Admin Orders.
This module will add a dowp down box to payment methods that will allow you to enable it for admin orders. If the payment method you use does not have this drop down you will need to edit the modules /etc/system.xml file and add in a node that corresponds to your payment method.

Here is an example of adding a new payment method to the module. I edit the file /app/code/community/Sharpdot/SharpAdminOnlyPayment/etc/system.xml

//This is the origional code for a bankpayment. I just need to duplicate this and adjust the code to reflect a new payment method.
<bankpayment>
	<fields>
		<admin_active translate="label">
			<label>Admin Override Enabled</label>
				<frontend_type>select</frontend_type>
				<source_model>adminhtml/system_config_source_yesno</source_model>
				<sort_order>1</sort_order>
				<show_in_default>1</show_in_default>
				<show_in_website>1</show_in_website>
				<show_in_store>1</show_in_store>
		</admin_active>
	</fields>
</bankpayment>

//This is the adjusted code for a new payment method. This is a made up payment method, with the code "sharppayment". You would just need to substitute your payment methods code.
<sharppayment>
	<fields>
		<admin_active translate="label">
			<label>Admin Override Enabled</label>
				<frontend_type>select</frontend_type>
				<source_model>adminhtml/system_config_source_yesno</source_model>
				<sort_order>1</sort_order>
				<show_in_default>1</show_in_default>
				<show_in_website>1</show_in_website>
				<show_in_store>1</show_in_store>
		</admin_active>
	</fields>
</sharppayment>

Download Module

Note: I am working on updating this module to automatically recognize all payment methods, so that editing the system.xml file will not be required in the future.

If you want password fields to maintain there entered values when a form is submitted, but is not valid your need to call “setRenderPassoword(true)” on the password element.

I have ran into an issue/bug with zend studio/eclipse IDE, every once an a while code completion will stop working. I have not been able to pin down what exactly causes the problem, but here is my fix.

Delete the following file in the Zend Studio workspace:

Zend/workspaces/<your workspace name>/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.dltk.ui.prefs

This is my upgrading Magento to Version 1.4 journey.

Here is how I decided to go about it.

• Backup the database!!
• Clear all cache and disable caching
• Move code into a SVN Branch (assuming you use source controll, if you don’t you should!)
• Remove Old Core Magento Code (just leave community and local modules, keep my theme folder)
• Download Full Release from Magento’s Website(don’t use the downloader, use the full release!)
• Extract the New Release into the SVN Branch that was created earlier
• If your template was a sub-template of anther theme then you need to merge them together to use in 1.4. This is due to the fact that 1.4 changed a bunch of classes and layouts. Or you could start from a fresh theme and re code it.
• Change the theme to a default theme until you are sure that the update went ok.

Errors and Bugs I came across:

• When Trying to run indexing I got the following error, “can’t initialize indexer process”. This was because I was missing some database tables that failed to install during the upgrade. I installed and ran the database repair tool.
• Had to disable WYSIWYG so that page templates did not get messed up.
• The file “catalog/product/list/toolbar.phtml” changed quite a bit, so if you modified this file grab the new one then start from there. Also the file “page/html/pager.phtml” needs to be update the the 1.4 version if you modified this file.
• When editing or adding products the Category Tree was only showing the Default or Root Category.
  To Fix this I just created a new subcategory of the root catalog and move all the categories into this new category then move them back to there original position. This must rebuild what ever was messed up in the database.

I recently had to migrate data into Drupal. To do this I decided to just run drupal_execute(), to create the nodes. I ran into a few quirks and thought I would share my trials with the world.

My first issue was, How do I get the new node id that was created by drupal_execute(). Well It was easier than I thought. I did a little goggling and found people saying that you should use db_last_id(), well that did not work for me. Instead I used the “$form_state” variable that I passed into the drupal_execute function. I noticed that after running drupal_execute() I could use $form_state['nid'] to retrieve the nodes id. Wow wasn’t that easy.

The nodes I was creating were using cck fields. I noticed that only the first node’s cck fields were created correctly. All subsequent nodes were created with cck fields containing just 1 character(I believe this only happened on select fields). To fix this issue I had to use the node id that I retireved and set the cck fields again. Then do a node_save(). Now all my fields are correct and I can go Fishing.:)