Well this morning I said I was going to start working on a simple SMTP extension for Magento. The weather was completely stink here in Auckland so I ended up making the ASchroder.com SMTP Pro Magento extension this afternoon you can get it from Magento Connect. It’s a development release and I’m seeking feedback on it from people willing to give it a try.
Continue reading SMTP Pro Magento extension, free and open SMTP support for Magento
Tag: Magento
Google Apps Email/Gmail Magento Extension v0.5 released
It’s been a while since I have written any updates on my Gmail and Google Apps email extension for Magento. I have just released version 0.5 and thought now would be a good opportunity to write a quick update on the changes and what I have planned for SMTP email support in Magento.
Version 0.5 of Google Apps Email/Gmail Magento Extension
Firstly the changes in the latest release of the Google Apps/Gmail Magento extension. Both have been inspired by user feedback so two ‘thank you’s to follow. Firstly thanks to Blue Acorn for pointing out the lack of multi-store capability on the self test. It’s actually a little clunky getting the store parameters in the admin of Magento, my custom button needed to add the parameter like so:
$buttonBlock = $this->getElement()->getForm()->getParent()->getLayout()->createBlock('adminhtml/widget_button'); $params = array( 'website' => $buttonBlock->getRequest()->getParam('website') ); $url = Mage::helper('adminhtml')->getUrl("googleappsmailtest", $params); |
And then the controller needed to actually pick up which Magento store to get the config for:
$websiteModel = Mage::app()->getWebsite($this->getRequest()->getParam('website')); $to = Mage::getStoreConfig('contacts/email/recipient_email', $websiteModel->getId()); |
The other change was a bit of a curve ball. I had a Magento + Gmail user named Matt contacted me with what seemed to be an unrelated issue. I have been poking around in the installation code trying to figure out what has been happening. It wasn’t until I did a full fresh install on Magento 1.3.2.3 that I noticed what was going on. My extension has a dependency on Mage_Core (obviously, right?) and the wiki guide on how to package Magento extensions says to include this dependency. However if you do then the downloader will download the Core files and a whole bunch of other required files. This is no problem if you have been a good boy or girl and made your changes to the themes outside of the default files, but if you have changed the default templates then there is a risk of your changes being lost!
So, the change is to remove this dependency, even though the guide says it should be there. It’s kind of obvious that you need Magento in order to run my extension anyway!
Magento SMTP support
The other update I wanted to post was that I am working on porting my Magento Gmail / Google Apps extension to also support full SMTP capability. I will be releasing the changes as a new extension, as it is important to me that the original goal of this extension (extreme simplicity and ease of use) is not lost under the weight of full SMTP configuration.
I know that there is already an older SMTP extension for Magento. I think I can improve upon it in several ways, I have developed Magento SMTP self test capability, and I have support for Magento newsletter sending. The current SMTP extension hasn’t been updated for nearly a year, and I have an opportunity to create a more modern, user friendly extension.
I’ll be working on it over the next few days and would invite feedback from anyone with ideas on ways to improve the Magento SMTP functionality.
Magento Google Base error: Expected response code 200, got 403 Service forbidden: Account not registered for Google Base
After some initial Google Base problems with Magento 1.3.2.1, I thought everything was going to be fine, only to get whacked with this error: Expected response code 200, got 403 Service forbidden: Account not registered for Google Base. I checked and checked again that my email/password was right, and that the Google account was registered for Google Base.
There wasn’t much help surfacing on Google for it, so I thought now that I have sifted through everything and looked at various sources, I’d compile a bit of an explanation and help guide for it. Please note this only affects 1.3.2.1, it is fixed in the newer versions of Magento, so unless you are wed to your current version, upgrade!
I posted a forum message on the Google Base boards and got this helpful reply:
- verify the application is not exceeding the api
limits of approximately 5 requests per second; - verify the proper uri is being used for the request.
- verify all the required attributes and proper values
are being used for the item-type being inserted —
check that all the rules for the item-type are being met.
Given my products were not anything special, I doubted the last option. Also given others were reporting success with the Magento Google Base capability (once the initial problem was fixed), I assumed it wasn’t the 5 requests per second problem either. So what was wrong with the request URI?
Well, to cut a long story short, it seems that my problem was due to the account being used for Google Base, also being a Google Apps account. If you’re interested in the details check out the login options for the Google Account API. The hosted Google Apps account did not have Google Base, but the Google account (with the same email and password) did. The login was succeeding, but then the account that was logged-in did not have access to Google Base!
The fix is to tell the GClient API to use the Google account only, not the HOSTED_OR_GOOGLE
default. I found others have suggested this fix (or the workaround of using a non-Google Apps account) here.
The gist of it is to change this function call by adding two extra parameters: app\code\core\Mage\GoogleBase\Model\Service.php on line 49. The two parameters to add are: Zend_Gdata_ClientLogin::CLIENTLOGIN_URI, 'GOOGLE'
as shown below.
$client = Zend_Gdata_ClientLogin::getHttpClient($user, $pass, Zend_Gdata_Gbase::AUTH_SERVICE_NAME, null, '', $loginToken, $loginCaptcha, Zend_Gdata_ClientLogin::CLIENTLOGIN_URI, 'GOOGLE'); |
That fixed the problem for me, now I just have to figure out which of the required Google Base attributes I’m missing!
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.
Update March 2013: There’s an extension for doing this now guys, thanks to Roman. Go get it!
Masking Password fields in Magento Extensions
Wow, long time, no post – no excuses really*, just been really busy. This post will give you a quick tip for masking password fields in your Magento extensions. I wanted to mask the password in my Google Apps and Gmail Magento Extension and despite a few Google searches, I couldn’t find a simple answer. There’s also not really any good documentation on the various configuration xml files in Magento, it seems.
Thankfully i960 over at the Magento forums gave me this simple tip, which I think should be shared. Here’s how to mask or hide your admin passwords in the backend of Magento. This is particularly useful when creating your own Magento extensions.
In etc/system.xml
add xml like this:
<password translate="label"> <label>Password</label> <frontend_type>password</frontend_type> <sort_order>10</sort_order> <show_in_default>1</show_in_default> <show_in_website>1</show_in_website> <show_in_store>0</show_in_store> </password> |
The key being the frontend_type of password in case you hadn’t noticed that.
Anyway expect me to be a bit more active with some Magento tips over the next few weeks.
*In a lot of ways you can blame Amazon for creating some of the worst financial reports I have ever had to work with! Parsing those to pull meaningful information has been like pulling teeth. Anyway I’ll add some feedback on those in an upcomming post.