Virtuemart Expert

During the last days we received a huge number of new users. Normally, we are happy about this - but these users were no "real" users. We received about 50 new registered users per hour, which was really annoying, because they obviously were no new customers. They were registered by (i guess) script kiddies. I really don't like "captchas", because the only annoy the real user. So we had to find another way.

If you also have this kind of "users" and your shop only needs the registration during the checkout (like vm-expert.com), you may find the following solution helpful (though it needs a hack):

You have to edit the following files:

/components/com_user/controller.php
/administrator/component/com_virtuemart/classes/ps_shopper.php

search for "function register_save()" (without the quotes) in both files. You will find the function blocks. Put the following line AFTER the "global $mainframe...." line:

if(!$_SESSION['cart']['idx']) $mainframe->redirect('/index.php','You can only register during checkout!');

This will prevent the user-registration if the cart is empty and redirect the user to the homepage showing the message "You can only register during checkout".

Additionally, you can overwrite the joomla register template to deactivate it. Just create a new directory under your active template root in the html-directory: com_user/register. Put a file called default.php in the register-directory and write a kind message that you only allow registration during the checkout. You can see our example when you click on "create an account" below the login fields at the top of the page.

After these changes, the spam registrations stopped immediately and as i tested on my own, the registration for real customers (with something in the cart) still worked. Let me know, if you discover any problems...

Hundreds of osCommerce shops have been hacked and are now used to spread malware and trojans. According to heise.de (a large german IT-magazine), the hackers used a security whole in osCommerce that has been fixed nine months ago!

OK, you might not use osCommerce - but this leads to the question "When did you last update your site"? Are Joomla, Virtuemart and other extensions on your site up to date? If not, this might be a possible risk for you and (more important) for your users.

When we are asked to work on Joomla/Virtuemart sites, we often see old versions in use. Often, the shopowner is not aware that there are update or he is afraid to install it (maybe it might break the site). To be honest, it is your job to keep the site updated! If you can't do it on your own, let somebody do it for you. It is not so difficult to set up a copy of the live-site to test the update and there are tool to create backups to be safe if something goes wrong.

Unfortunately, a lot of sites use core-hacks for special functions. Mostly, these functions could have been created without hacking the code - but at least it should have been documented so that you know the changed files and are able to compare with the patch files. As a last help, there are "Diff-Tools" that can check differences in whole directory trees.

If you don't have Joomla 1.5.23 and Virtuemart 1.1.9 installed**, you should update NOW!

** the newest versions when this blogpost was written

Sometimes you may want to show a module only when the user has products added to the cart. With the "Advanced Modulemanager" from NoNumber.nl this is very simple. Just open the module in the module manager, open the slider "Module Assignment" and scroll down to the last entry in the list. This should be "PHP". Click on the first radio-option. Now there should be a textbox where you can enter php-code. Just type this simple line:

return $_SESSION['cart']['idx'];

and save the module. From now on, the module will appear only when the user has added at least one product to the cart.

[UPDATE] In Virtuemart 2.0, the cart is stored in a different way. This solution will not work in Virtuemart 2.0. You can check the file mod_virtuemart_cart.php to see how the content of the cart is checked (see $data->totalProduct).

Peter van Westen / Nonumber.nl has released a new plugin these days: "Tooltip". It is still beta, but already works very well. This plugin allows to add tooltips to content very easy - and it is also possible to add image-tooltips. This is what this tip is about:

Use Nonumbers Tooltip plugin to show the product-full-image in Virtuemart

It is very easy to add a simple image-zoom with this plugin. Open the templatefile of your theme where you want to use the plugin - e.g. /components/com_virtuemart/themes/default/templates/product_details/flypage.tpl.php. Find the place where the thumb-image is displayed. Here it is

<?php echo $product_image ?>

Enclose this PHP-block with the tooltip plugin tag and add the full-image-url. In our example, it could look like this:

{tip <img src="<?php echo IMAGEURL.'product/'.ps_product::get_field($product_id,'product_full_image'); ?>" class="vmxtooltipimage">}<?php echo $product_image ?>{/tip}

This should be enough to display the full-image when you move the mouse over the thumb. Example:

BTW: if you sometimes have very large full-images, you can also add the full-image with virtuemarts resize-tool (show_img_in_imagetag). If you don't want to do this, there is a CSS trick to scale images: max-height: 300px;max-width: 300px; This will scale the image proportional to a max of 300px on each side. It works in most modern browsers. (The full image is still loaded. It will just be displayed smaller. This is no way to save bandwidth.)

The current release of Virtuemart (1.1.9) handles empty categories different from previous versions:

If a category does not contain any products, also subcategories are not shown - even if they contain products. There is a thread in the virtuemart forum discussing this behavior.

If you have problems with this "new" behavior, you will have to change the line 86 in /administrator/components/com_virtuemart/html/shop.browse.php to this (there is just a "!" added):

elseif( $num_rows == 0 && empty($product_type_id) && !empty($child_list)) {

This will change the behavior back to how it was in the previous versions.

I have checked the list of our registered domain names this week. There are some domains i have registered over the years with an idea in mind – but as often, there was not enough time to realise the ideas.

Here is a list of domain names i would like to offer, because i don’t think that i will use them in the near future. Maybe some of them could be interesting for you:

• extensionclub.com + extension-club.com
• j-cck.com
• planetjoomla.com
• joomhelp.com
• joomservice.com
• joomlanetwork.com
• joomlanetzwerk.de
• vm-exchange.com
• vm-remote.com

If you are interested in one (or more) domain names in this list, please send me an offer through the contact form of this site.

This is the first time i am selling domain names – and i don’t have an idea what they could be worth. For each domain i have a minimum price in mind. Below that, i would not sell them. Just let me know what they are worth for you.

Payment can be done through paypal. You will receive the Domain right after the paypal transaction including an invoice. If you are a company, please submit your VAT-Id.

Today Fabian Petzold from fpCOM - IT Professional informed us about a security problem in the notify.php of the paypal payment module. Together with our friends at Sobi / Sigsiu.NET we could reproduce this problem: it is possible to change the order status to "confirmed" (=payed) without really paying the order through paypal.

I will not describe how this can be done ;-) but all notify.php versions are affected (not the new paypal express api!). We have created a patch for this problem (for Joomla 1.5.x!). This is new and tested only on some sites. So, if you use this patch, please try a purchase on your site to see if normal transactions are handled correctly. We have given this patch to the Virtuemart Team for testing and releasing an update.

Edit the file /administrator/components/com_virtuemart/notify.php. Go to line 310. This should be the line before this comment:

//--------------------------------------------------------
// If connected OK, write the posted values back, then...
//--------------------------------------------------------

// VM-Expert fix: do not allow transactions in sandbox without Debug-Mode   
    elseif(JRequest::getInt('test_ipn')==1 && PAYPAL_DEBUG != "1") {
	    $res = "FAILED";
        
	    $mailsubject = "PayPal Sandbox Transaction without Debug-Mode";
	    $mailbody = "Hello,
	    A fatal error occured while processing a paypal transaction.
	    ----------------------------------
	    Hostname: $hostname
	    URI: $uri
	    A Paypal transaction was made using the sandbox without your site in Paypal-Debug-Mode";
	    vmMail($mosConfig_mailfrom, $mosConfig_fromname, $debug_email_address, $mailsubject, $mailbody );
    }
    
 // VM-Expert fix: end

With this patch it is not allowed to call the notify from a sandbox transaction without the debug mode switched on. The Shop-Admin will be informed by mail that this has been tried.
If you have any problems using this patch, please contact us or write a comment on this page.

If you are using Joomla 1.0.x, replace the string

JRequest::getInt('test_ipn')

 with the following:

trim(stripslashes($_POST['test_ipn']))

Just a short tip if you have problems with a high MySQL-Serverload in your Virtuemart shop. If you have a large number of products and the manufactuter searchmodule activated (mod_virtuemart_manufacturers), it may be that searchengines are "killing" your database by submitting the manufacturers searchform without selecting a manufacturer.

Virtuemart then searches all products (like with "list all products") using the shop_browse_queries.php. If you have a lot of products (>10000) or categories (>500), this might lead to queries the produce "temptables on disk". This happens, when MySQL cannot handle the query in the cache / memory. This is one of the worst things that could happen - because it is extremely slow and it will lead to waiting queries in the queue. You can find out if your database produces these queries when you open the Process-List in phpMyAdmin. The list shows you the status of the queries and the time they need for execution.

What we have done to avoid this is that we check for a "valid" manufacturer search.

Edit /modules/mod_virtuemart_manufacturers/mod_virtuemart_manufacturers.php and add a hidden field to the form - like this:

Then edit the file /administrator/components/com_virtuemart/html/shop_browse_queries.php and add some code at the end of the file to check if the manufacturers search is called and if there is an ID:

Now the query is resetted and an information is shown for the user. This will avoid unwanted large and complex queries. Without this change (and some more optimization), a shop of one of our support-ticket-customers was nearly unusable when searchengines were on the site.

The Virtuemart Team has just released a security patch called "1.1.7a". You can find more information about this here: http://virtuemart.net/security-bulletins/396-vm-security-bulletin-2011-02-18.

The version could make you think that the patch file could only be used for VM 1.1.7. What is not written there is, that you can use the patch for earlier versions of Virtuemart, too. We have checked Versions back to 1.1.4. The only affected file is the ps_module.php from the classes directory.

If you cannot overwrite this file for any reason, go and edit the file and replace the function "get_dir" with the 1.1.7a version. This is where the problem lies.

Don't leave it unchanged. This is a real risk!

An hour ago packetstormsecurity has published a Virtuemart security problem over twitter. You can find the full description here: http://packetstormsecurity.org/files/view/98032/joomlavirtuemart116-sql.txt

From a first check it seems, that the problem is an unchecked variable used in the internal Virtuemart search. You can fix this by replacing the following line in /components/com_virtuemart/virtuemart.php (should be around line 35)

$search_category= vmRequest::getVar( 'search_category' );

with this one:

$search_category= vmRequest::getInt( 'search_category' );

This makes sure, that the parameter "search_category" is always an integer.

If there are other things affected by this security hole, i'll update this post.