Stephen Rushing

I noticed that when displaying the Enterprise Banner Widget in “fixed” mode, the order is ignored. I thought it might have something to do with my template, but the template that ships with the Widget (/app/design/frontend/enterprise/template/banner/widget/block.phtml) does the same thing.

I tracked the order issue down to Enterprise_Banner_Block_Widget_Banner::getBannerIds() in /app/code/core/Enterprise/Banner/Block/Widget/Banner.php, line 137.

$bannerIds = $this->_bannerResource->getExistingBannerIdsBySpecifiedIds($bannerIds);

That’s Enterprise_Banner_Model_Mysql4_Banner::getExistingBannerIdsBySpecifiedIds() in /app/code/core/Enterprise/Banner/Model/Mysql4/Banner.php. It’s making a call to the database to see which of the banners are enabled, and then returning the id column, sorted, so the items always end up ordered by the banner id, rather than the specified order.

To fix this, I copied /app/code/core/Enterprise/Banner/Model/Mysql4/Banner.php to /app/code/local/Enterprise/Banner/Model/Mysql4/Banner.php and changed getExistingBannerIdsBySpecifiedIds() to the following:

public function getExistingBannerIdsBySpecifiedIds($bannerIds, $isActive = true)
{
$adapter = $this->_getReadAdapter();
$select = $adapter->select()
->from($this->getMainTable(), array('banner_id'))
->where('banner_id IN (?)', $bannerIds);
if ($isActive) {
$select->where('is_enabled = ?', (int)$isActive);
}
$existingIds = $adapter->fetchCol($select);
foreach($bannerIds as $key=>$bannerId){
if(array_search($bannerId, $existingIds) === false){
unset($bannerIds[$key]);
}
}
return array_values($bannerIds);
}


The only changes are from $existingIds = … return array_values($bannerIds).

Instead of returning the column straight from the database, we loop through the $bannerIds that were passed to the function, unset the keys that don’t exist in the database col, then return a 0-N indexed array with array_values().

A friend recently told me about the open source e-commerce software, Magento. It looked much nicer than osCommerce and ZenCart, so I wanted to give it a try.

Most of what I found involved setting it up in Apache, but I did come across one well-written guide on installing it in IIS.

I got to page 2 of the walkthrough and read, “There is no need to go into details about each extension, but something worth mentioning is that you cannot have both php_mysql.dll and php_pdo_mysql.dll enabled. Magento uses pdo_mysql, and if you enable both, php_mysql takes presedence over pdo_mysql, so keep this in mind.”.

AH! I just jumped through several hoops to get mysql working for Wordpress. And obviously, the generic mysql extension is required by too many things to disable it. I decided to move on with fingers crossed…
** NOTE: I did not run into a conflict with having both enabled. Maybe this has to do with php_pdo_mysql being declared before php_mysql. **

Also, I did not see an ISAPI_Rewrite tab in my IIS Web Sites properties after installing it; although, there was an entry for it in the ISAPI Filters. I went to the Rewrite Manager in Start > Programs > Helichon, and saw pretty much the same output as the guide’s screenshot.

This tutorial states it assumes we downloaded Magento build 1.0.19870.1, but 1.1.2 was out now, so I went for that instead.

After handling a couple of permission issues (described in the guide), the Magento installer started!

I got to the Configuration section and got thse messages:

• PHP Extension “mcrypt” must be loaded
• PHP Extension “curl” must be loaded

Those extension lines were already uncommented in my php.ini, so I did some searching. This post says to place libeay32.dll and ssleay32.dll in the windows\system32 directory. I did so, restarted IIS, and the curl message dissapeared.

I figured the mcrypt problem was related to the curl and mysql issues I’d had, where I needed to place the dll directly in windows\system32 (still no idea why IIS doesn’t read from the Path environment variable). So, I copied libmcrypt.dll to my system32 dir, restarted IIS, and it worked!

Now, I could browse around the admin area, but all the links on the front end were broken. I noticed the admin area had index.php/ before most of the paths (like my Wordpress blog), but it was missing from the links in the front end. The guide had me add index.php to a config.php file, so I assumed the same had to be done for the URLs on the front end. Sure enough, http://MYURL/customer/account/login/ didn’t work, but http://MYURL/index.php/customer/account/login/ did.

Currently trying to resolve this on the Magento Forums. I’ll update this post once it’s all squared away.

I have found that disabling the URL Rewrites in Admin > System > Web works, but the URLs aren’t quite as friendly.

**UPDATE 8/10/2008**

As excited as I was to get this up and running in IIS, there was too much of a speed issue. I’m giving SimpleHelix Hosting a try, per the recomendations on a Magento Forum post.