We are proud of the quality of our extensions and find that in most circumstances there are no issues with installation and getting the most out of your chosen extension. However if you do come across an issue this general troubleshooting page provides information relevant to many extensions.
If you think that the issue is a general one e.g. general installation or setting up a CSV file then please check here for guidance. If you think your issue is more extension specific then please refer to the troubleshooting pages behind your chosen extension. There is some crossover between the two but all issues should be addressed in these sections.
"Fatal error: Class 'Mage_Wsacommon_Helper_Data' not found in /home/yourdomain/yoursubdomain/app/Mage.php on line 520"
"Fatal error: Call to a member function toOptionArray() on a non-object in
/home/yourdomain/yoursubdomain/app/code/core/Mage/Adminhtml/Block/System/Config/Form.php on line 385"
Copy the files over again and ensure each and every file copies sucessfully.
Please take a look under your particular extension, there are screencasts, examples, & troubleshooting guides to help you.
If you are still having issues then raise a support call to firstname.lastname@example.org
We do not password protect our ZIP files, if you are asked for a password when trying to extract your extension it may be that the directory structure is too long. (I.e C:\downloads\long directory name\long directory name\unzipped folder\...), try downloading the ZIP to the C: drive and extracting there.
You are trying to install a 1.3 extension onto a 1.4.* Magento release. When you purchase the extensions you will have 2 zip files - one will be marked with M1.4. Make sure you install this on Magento 1.4.* releases. Upload over the existing 1.3 release and refresh the back end with cache disabled.
This error means that your new attribute has not been indexed yet.
After installing an extension you should re-index all indexes and refresh the cache - always keep the cache disabled during modifications and re-index whenever new attributes are created.
This problem occurs in 1.4 Magento, and some of the shipping extensions expose it. Please contact us directly from this sales link for an updated extension.
Please make a full database backup and Magento backup before proceeding. We can not be held responsible for any loss of data or revenue. If you are unsure of what you are doing we recommend consulting with either us or your developer.
This means the extension or Magento can not find a table in the database.
If this happens when you first install an extension it means the SQL has not run. This is usually caused by a race condition in Magento whereby multiple entities are trying to access the same resource.
To resolve this you need to login to your database and find the table called "
This will force the SQL to be re-run after refreshing the frontend.
If you manually remove an extension and the SQL tables/entries, when you re-install you may find that the SQL side is not re-entered. This is expected behaviour. From a Magento perspective, it has no idea that you have manually removed the files.
Be careful when following the actions below, as it will re-run all the SQL from the initial install. This may result in your site crashing if it cannot re-run the SQL successfully. I recommend you understand what the SQL is doing before you invoke it.
To look at the SQL find the SQL folder under the extension directory. There will be an
It should be stressed that as long as you do not remove the SQL when you uninstall an extension you should never have to re-install, so this should not be an issue.
If your site does crash, then I recommend you replace manually the row you have deleted in
No liability can be accepted for misuse of the information above, please be aware this could cause problems if you do not fully understand what you are doing. If in any doubt we highly recommend you contact us to do this for you at sales. There is a consultancy charge for such work as it outside the scope of extension sales.
There is a problem that affects a minority of users when installing an extension with this error. This is because of a MySQL bug - a quick search on Google shows the issue.
You will need a revised SQL file to resolve the issue. You are advised to disable the extension temporarily to prevent your site from experiencing any more issues in the mean time. If the the complaint is about the unique keys, go to your SQL install script in app\code\local\Webshopapps\Productmatrix\sql\productmatrix_setup (using Product Matrix as example) and open the latest version into a text editor.
Find the line declaring UNIQUE KEY and remove this line. On the PRIMARY KEY line above, delete the last comma "," and save. Upload this over existing install script, clear your cache and keep disabled. Refresh the front end - if no errors are picked up you are resolved.
Otherwise, Disable the extension by renaming the relevant extension file from app/etc/modules, to e.g. Webshopapps_ProductMatrix.xml.orig refresh front end, rename and remove .orig and refresh again.
If you see an error complaining about duplicate entry with the word setup in it then it is probably because you have already installed this module before in some form.
Firstly check the appropriate SQL file to ensure that you do actually want to run it - in this case under freeoptionalshipping_setup. If not then comment out the main SQL section.
Then remove the entry "freeoptionalshipping_setup" from the table core_resource
If you can not see the extension then it is either because you havent installed the files in the correct location, or because you havent refreshed the cache.
You should have extension related files under
Webshopapps was formerly known as Auctionmaid, so you may see extensions under the Auctionmaid banner
When you try to save an invalid serial key - it will not be immediately erased. Only after you try to execute functionality of the extension will the serial key will be erased.
In most cases you will know this when you try to get a shipping rate using one of our shipping extensions. Get the server name of your Magento installation again and contact us to resolve the situation.
In most cases it is possible to disable an extension by renaming the relevant .xml file in app/etc/modules. You must rename to be non .xml e.g. Webshoppapps_Productrate.xml.orig.
To enable reverse the process.
Here are the steps for removing a shipping extension. All our extensions sit in the app/code/local or app/code/community areas, so there is no impact on core code.
This problem occurs as Magento is not very good at clearing out shipping methods when you delete them. The shipping method can be the name of any shipping extension you have deleted.
Suggest you backup your database first, especially if you are not comfortable around sql.
To resolve go into phpmyadmin, get up a SQL prompt and do the following:
If you are happy that the result set is that which you want to delete (should be around 15 rows) do following:
If you get invalid SQL syntax can you replace the quotes above with quotes
Replace MatrixRates where appropriate.
Some of our extensions now have a debug switch where you can get logs that can be sent across to us to enable us to diagnose configuration issues.
To use this feature:
If you are unable to retrieve any shipping rates, and are using Excel on a Mac can you make sure you save the files in Windows CSV format. This is a known issue, and documented by Magento for tax imports here
You can confirm this issue by looking in the table where the csv file is uploaded. The table name is likely to be
The option is referring to which product the extension looks at when getting the shipping group for bundled and configurable items. Should the extension look at the actual bundle/configurable item shipping group? Or look at the shipping group of the individual products that make up the bundle products?
This option enables you to choose whether to use "LARGE" and "SMALL" as shipping groups from the child products or whether to use "BUNDLE" from the parent.
In this scenario you may wish to define shipping based on the fact it is a T-SHIRT or the fact it is LARGE or SMALL. The "Use Parent" shipping option provides this.
Remember to ensure your shipping group association created is the same as in your CSV file, case sensitive.
Where the shipping group attribute is used to assign products to a group - it may have "Use to Create Configurable Product" field set to "Yes". In actual fact, by default this should be set to "No" - this may mislead you when creating a Configurable Product and show the shipping group as a selectable choice to the customer (which is very undesirable) and would also amount to the Configurable Product not having the "Shipping" tab available - meaning no shipping group is selectable for it either.
So to fix this, just make sure"Use to Create Configurable Product" is set to "No" and re-do the Configurable Products where they have been mistakenly set up with the Shipping Group attribute. You will then be able to assign the group correctly and get back rates when the Configurable Product is in the cart as expected. In Product Matrix this attribute is "package_id", if you have another extension which uses shipping groups,refer to the documentation in order to know which attribute it is.
Ensure the Shipping group and associated attributes are in the attribute set of the product you are editing - they are only in the default attribute set on extension install.
Shipping extensions will generally be agnostic to tax settings, and they will always calculate based on the tax exclusive price. So if you are using something like Matrixrate and the Price filtering make sure you bear this in mind. Webshopapps do produce extensions that work on the tax inclusive price, but we would recommend if you can stick to standard magento you should do so.
If you are experiencing rounding issues around tax then this forum article may help:
The full error will look something like this:
If you want to add locale support for your CSV file you manage this via the
So, if for instance you want to specify shipping as Courier on your UK store and Kurier in German then in the
On some of our extensions we have now added a debug switch where you can get logs that can be sent across to us to enable us to diagnose configuration issues.
To use these feature:
In some circumstances, it may be advantageous or necessary to filter shipping based on the packages destination post/zip code. This is achieved in a number of ways:
To specify a range of post/zip codes: These must be numerical only, I.e. 90210 is acceptable, W5 2LH is not.
To match a post/zip codes pattern: Use the field "Post/zip code from"
To match all post/zip codes beginning with a a sequence. I.e. to match any postcode beginning with 902 you would enter 902%.
This is very powerful but doesn't fit all requirements, such as if you need to use UK postcodes and treat the postcode EH12 2JK differently from EH1 2LD as entering just EH12% would potentially match both if no space is present. This can be solved by creating rules using "_" which represents one and only one character of any type. So you would create a rule such as such:
If you do not want to use the post/zip code field, you can enter * and it will be ignored.Note: The postcode logic uses mySQL regular expression syntax - for more info see here
You will see this problem if you have not got the correct amount of columns defined in the CSV file. Check an example file and compare it with your own.
Sometimes this occurs when you have a last column (e.g. Notes) which has no values. If you open in Word pad you will see some rows with a comma at end and some without. To ensure it works try putting a * in the last column if not using.
CSV means comma separated values. Unfortunately in Europe (ex UK) Excel is configured by default to use ; as the delimiter, rather than ,
This causes a problem for the extensions as they only upload based on comma delimiters. We could obviously change this, but have chosen not to, in order to stay in line with standard Magento. We realise this is an inconvenience to our European partners but assume you will hit this problem elsewhere in Magento (e.g. Taxation files, product imports) so hopefully you can see the reasoning behind the decision.
The quick solution to opening comma separated files in Excel then do Data >Text to Columns and then selecting comma as a delimiter.
The better solution is detailed in following link - solution #3
An error like this when you upload a CSV file means you do not have the correct amount of columns:
Please read documentation and see examples to see the amount of columns. For the Product Matrix CSV it can be one of two formats, 15 or 17 columns. If you add in the algorithm column you must also add a notes column at end.
If you see something like above it means you are trying to put in 2 entries which would match the same logic including delivery price. Check through your CSV file to ensure you have no duplicates. The Row # is an indicator as to the row the problem is on in some cases.
This field can be left with a
Firstly check you have regions - these can be seen in the drop down on the cart shipping estimator. If you don't then try downloading your countries locale extension. Otherwise you may need to define yourself (if you wish to use).
If you have region codes you need to use the short code in the CSV. This correlates to the 'code' field in the database table directory_country_region.
For example in the USA valid codes are AK, CA, NY, etc.
The values in the region/ state field (from csv) are converted into numeric values before they get save into the database by directory_country_region table. For example:
The country codes in Magento should conform to ISO3166 (aka ISO3) standards - see the list here
There are some anomolies though, in particular Romania is ROU according to ISO3 but ROM in Magento pre-1.4. Magento have fixed this for 1.4 onwards (and Enterprise), so be careful if upgrading. There are a handful of codes like ROU, I dont have the full list.
If you look in phpmyadmin at the table directory_country you will get the full list of ISO3 codes used.
If you look in directory_country_region you will get the full list of region/state codes used. If you want to say remove some of the military states then you can do by modifying this table.
Please see here for a list of google country codes
I use TextPad to do this. If we have the following set of postcodes:
Firstly copy out all your postcodes into TextPad. Then do a regular expression search/replace for "$" replacing with ",". This will put a comma at end of each line:
Now to concatenate, you can either do it manually, or use the TextPad macro "Carriage return remove" from here. You should end up with; PA11,PA12,PA13,PA14
Note: this setup of filtering only currently works with ProductMatrix v11.1 and above. It is shortly to be rolled out on other commercial extensions such as Premium MatrixRate.
By default excel will trim the leading zeros from numeric values which is not very helpful if you are trying to set up zip code logic.
To stop excel doing this follow these steps:
Create a new numeric format by:
Now select the applicable cells (probably your entire zip to / from column) and apply this new format.
If you are using a shipping extension with post/zip code pattern matching and it is not functioning as expected please ensure you have the option "Use Post/Zip code range" from under " Configuration > Shipping Methods > WebShopApps xxxxx " set appropriately.
If you are using zip ranges - e.g. in USA or Australia such as 6550-700 then "Use post/zip code range" should be set to YES, otherwise it should be NO.
If it is still not working please ensure you are using the correct column in the CSV file, which is "Zip/Postal Code From" and "Zip/Postal Code To" - which is usually column "D".
Users in the UK (and Canada) can use the UK postcode filtering option.
This issue usually occurs when there is an issue around the formatting of your csv file.
Make sure you have not placed currency symbols in the shipping price column and that you have used the correct csv template with right amount of columns for your particular extension.