- Welcome to VirtueMart Forum.
VirtueMart Community Forum
News:
Looking for documentation? Take a look on our wiki
Recent posts
#41
Installation, Migration & Upgrade / Re: class does not exist Plgvm...
Last post by balai - August 05, 2026, 13:09:24 PMWhat happens if you enable Joomla's System Debug?
Are you getting more info about the source?
Are you getting more info about the source?
#42
Virtuemart Development and bug reports / Search ignores uncategorized c...
Last post by sandomatyas - August 03, 2026, 15:44:44 PMHi,
This looks like a logic bug in frontend keyword search (sortSearchListQuery), not a misconfiguration.
Setup (intentional)
Parent product assigned to a published category
Child products have their own SKUs, are published, and are intentionally not assigned to any category (category only on the parent)
show_uncat_child_products = 1
show_unpub_cat_products = 0
Expected
Searching by the child's SKU must return the child. That is exactly what show_uncat_child_products=1 is for.
Actual
0 results. The SKU match works in SQL, but the product is dropped afterwards by the category filters.
With show_uncat_child_products=1, search correctly builds:
((p.product_parent_id = "0" AND pc.virtuemart_category_id > "0") OR p.product_parent_id > "0")
so uncategorized children are allowed.
But then show_unpub_cat_products=0 unconditionally adds:
`c`.`published` = 1
For an uncategorized child, the LEFT JOIN leaves c.published as NULL, so NULL = 1 fails and the child is excluded.
So show_unpub_cat_products=0 silently cancels show_uncat_child_products=1. That is inconsistent: one setting explicitly allows uncategorized children, the other then rejects them because they have no category row at all (not because they belong to an unpublished category).
Suggested fix
c.published = 1 should only apply when a category is actually joined, e.g.:
(`pc`.`virtuemart_category_id` IS NULL OR `c`.`published` = 1)
Assigning every child to a category is not a valid solution here — the catalog is built on purpose with categories only on parents.
Thanks.
This looks like a logic bug in frontend keyword search (sortSearchListQuery), not a misconfiguration.
Setup (intentional)
Parent product assigned to a published category
Child products have their own SKUs, are published, and are intentionally not assigned to any category (category only on the parent)
show_uncat_child_products = 1
show_unpub_cat_products = 0
Expected
Searching by the child's SKU must return the child. That is exactly what show_uncat_child_products=1 is for.
Actual
0 results. The SKU match works in SQL, but the product is dropped afterwards by the category filters.
With show_uncat_child_products=1, search correctly builds:
((p.product_parent_id = "0" AND pc.virtuemart_category_id > "0") OR p.product_parent_id > "0")
so uncategorized children are allowed.
But then show_unpub_cat_products=0 unconditionally adds:
`c`.`published` = 1
For an uncategorized child, the LEFT JOIN leaves c.published as NULL, so NULL = 1 fails and the child is excluded.
So show_unpub_cat_products=0 silently cancels show_uncat_child_products=1. That is inconsistent: one setting explicitly allows uncategorized children, the other then rejects them because they have no category row at all (not because they belong to an unpublished category).
Suggested fix
c.published = 1 should only apply when a category is actually joined, e.g.:
(`pc`.`virtuemart_category_id` IS NULL OR `c`.`published` = 1)
Assigning every child to a category is not a valid solution here — the catalog is built on purpose with categories only on parents.
Thanks.
#43
Administration & Configuration / <lastmod> Tag not showing in S...
Last post by MAD King - August 02, 2026, 20:22:32 PMHello,
I can't figure out why the <lastmod> Tag is not showing in the sitemap XML.
Anyone has any idea?
Thanks.
VirtueMart 4.6.4 11226
Joomla 5.4.7
I can't figure out why the <lastmod> Tag is not showing in the sitemap XML.
Anyone has any idea?
Thanks.
VirtueMart 4.6.4 11226
Joomla 5.4.7
#44
General Questions / No more swiping, just real mee...
Last post by palacla - July 30, 2026, 04:07:13 AMReal women are waiting for you - No Selfie
https://girlsingle.com
Real Girls. Real Nights.
NEW GIRLS
Samanta Lily
Richelle Ryan
Sofiia
Scarlett Jones
Skye Blue
Kenzie Anne
Tori Black
Pepe Coco
Corinne
Mia Gag
Clara Blanc
Lauren Phillips
Sofia
https://girlsingle.com
Real Girls. Real Nights.
NEW GIRLS
Samanta Lily
Richelle Ryan
Sofiia
Scarlett Jones
Skye Blue
Kenzie Anne
Tori Black
Pepe Coco
Corinne
Mia Gag
Clara Blanc
Lauren Phillips
Sofia
#45
Templating & Layouts / Re: Can't override sublayouts
Last post by MAD King - July 25, 2026, 22:17:19 PMDid you ever find a solution because I am stucking at the same crap.
#46
General Questions / Re: This site has one or more ...
Last post by hotrod - July 24, 2026, 01:16:42 AMThank You... I will.... I have local cpanels I can load the site on and test.. It's how I moved to Joomla 4 I have template issues moving to J5.. that will come in the future.. Thank You for the response..
AI has been unbelievable helping me straight out Issues and changing things I want changed.. I just loaded this J4 Site 3 weeks ago from J3.. should have updated it then.. didn't know it already had an issue until now..
AI has been unbelievable helping me straight out Issues and changing things I want changed.. I just loaded this J4 Site 3 weeks ago from J3.. should have updated it then.. didn't know it already had an issue until now..
#47
General Questions / Re: This site has one or more ...
Last post by iWim - July 23, 2026, 15:21:46 PMVirtueMart is at version 4.6.8 at this moment.
VirtueMart is Joomla 5 compatible since VM 4.2.6 (released 29 January 2024).
Your version of VirtueMart (4.2.4) is close to 3 years old.
Joomla 4 is EOL since October 2025.
There have been several recurity releases.
VirtueMart news: https://virtuemart.net/news
I strongly recomend you update to the latest version*!
Remember, your webshop holds the personal data of your customers!
I recomend to test the update on a copy of your site first.
Create a backup with Akeeba Backup.
Install WAMPServer or MAMP on your computer to create a local server.
Copy and install your webshop on your local server with Akeeba Kickstart.
Update this copy.
This way you know what to expect during the update process and solve potential issues, without affecting your live webshop.
And if something does go wrong, you don't have to panic: just reinstall the copy and start over.
Note:
* There is a VirtueMart 4.9. This is the beta for VM5, do not use a beta on a live website!
VirtueMart is Joomla 5 compatible since VM 4.2.6 (released 29 January 2024).
Your version of VirtueMart (4.2.4) is close to 3 years old.
Joomla 4 is EOL since October 2025.
There have been several recurity releases.
VirtueMart news: https://virtuemart.net/news
I strongly recomend you update to the latest version*!
Remember, your webshop holds the personal data of your customers!
I recomend to test the update on a copy of your site first.
Create a backup with Akeeba Backup.
Install WAMPServer or MAMP on your computer to create a local server.
Copy and install your webshop on your local server with Akeeba Kickstart.
Update this copy.
This way you know what to expect during the update process and solve potential issues, without affecting your live webshop.
And if something does go wrong, you don't have to panic: just reinstall the copy and start over.
Note:
* There is a VirtueMart 4.9. This is the beta for VM5, do not use a beta on a live website!
#48
General Questions / This site has one or more vuln...
Last post by hotrod - July 22, 2026, 18:20:07 PMIs this fact? Can someone tell me what I need to update.. Update to 4.4.11? Wondering what settings I will lose on updating ? took a lot to get this the way I wanted it...
Plugin: VirtueMart (com_virtuemart) below 4.4.11 - Unauthenticated Reflected XSS and Authenticated SQL Injection
VirtueMart e-commerce component. CVE-2025-55757 (unauthenticated reflected XSS, affects 1.0.0-4.4.10) and CVE-2025-25228 (authenticated SQL injection in product management, affects 1.0.0-4.4.7). Fixed in 4.4.11. Rule pinned to component type because the Xmap and OSMap VirtueMart bridge plugins ship under element com_virtuemart at their own low versions.
https://nvd.nist.gov/vuln/detail/CVE-2025-55757
Plugin: VirtueMart (com_virtuemart) below 4.4.11 - Unauthenticated Reflected XSS and Authenticated SQL Injection
VirtueMart e-commerce component. CVE-2025-55757 (unauthenticated reflected XSS, affects 1.0.0-4.4.10) and CVE-2025-25228 (authenticated SQL injection in product management, affects 1.0.0-4.4.7). Fixed in 4.4.11. Rule pinned to component type because the Xmap and OSMap VirtueMart bridge plugins ship under element com_virtuemart at their own low versions.
https://nvd.nist.gov/vuln/detail/CVE-2025-55757
#49
Virtuemart Development and bug reports / Re: [BUG] Category pagination ...
Last post by wyder - July 15, 2026, 18:54:23 PMI can add another real-world confirmation of this issue.
On a production VirtueMart store, we had exactly the same behaviour:
However, the products from page 2 were still displayed.
The problem appeared only in some categories, which initially made it look inconsistent.
After comparing the Joomla menu items assigned to the affected and unaffected VirtueMart categories, we found an important difference.
Some category menu items contained only a short link such as:
After opening and saving the same menu item in Joomla, its link was expanded with additional parameters:
After updating the affected menu items, returning from page 2 to page 1 started working correctly.
The most relevant parameter for this pagination issue is:
Even though limitstart=0 is not visible in the final SEF URL, it is stored in the active Joomla menu item.
This appears to be consistent with Joomla routing behaviour. When parsing a URL, Joomla merges the active menu item's query variables with the variables parsed from the route:
Therefore, even if the SEF router removes limitstart=0 from the visible URL, the value can still be supplied through the active menu item and made available to VirtueMart during the request.
This may also explain why the issue appears only in some categories or installations:
In our case, the store contained approximately 600 VirtueMart category menu items, so opening and saving them manually was not practical.
We applied the workaround directly in the Joomla menu table.
First, we checked which menu items would be affected:
Then we appended the missing parameters only when they were not already present:
yourprefix_menu must be replaced with the actual Joomla menu table name, for example:
The Joomla #__menu placeholder cannot be used directly in phpMyAdmin.
A database backup should of course be made before running the UPDATE query.
After running the query and clearing the Joomla and VirtueMart caches, the affected categories correctly returned visitors from page 2 or later to page 1.
I did not test whether all the additional zero-value parameters are required individually. For this particular pagination problem, limitstart=0 is clearly the relevant parameter.
The other parameters were added because they matched the complete link generated after opening and saving a VirtueMart category menu item in Joomla.
This database change should still be treated only as a workaround, not as a core fix.
It depends on the request being associated with a matching Joomla menu item. It may not fully cover:
The system plugin proposed above is therefore a broader workaround because it acts directly on the incoming request.
However, the underlying issue should still be fixed in VirtueMart core. A bare category URL should reliably open page 1 instead of inheriting the previous limitstart value stored in the visitor's session.
On a production VirtueMart store, we had exactly the same behaviour:
- page 2 and subsequent pages worked correctly, for example:
Code Select
/category/results,81-160.html
- clicking page 1 changed the URL back to the bare category URL:
Code Select
/category.html
However, the products from page 2 were still displayed.
The problem appeared only in some categories, which initially made it look inconsistent.
After comparing the Joomla menu items assigned to the affected and unaffected VirtueMart categories, we found an important difference.
Some category menu items contained only a short link such as:
Code Select
index.php?option=com_virtuemart&view=category&virtuemart_category_id=2
After opening and saving the same menu item in Joomla, its link was expanded with additional parameters:
Code Select
index.php?option=com_virtuemart&view=category&virtuemart_category_id=2&virtuemart_manufacturer_id=0&virtuemart_manufacturercategories_id=0&clearCart=0&limitstart=0
After updating the affected menu items, returning from page 2 to page 1 started working correctly.
The most relevant parameter for this pagination issue is:
Code Select
&limitstart=0
Even though limitstart=0 is not visible in the final SEF URL, it is stored in the active Joomla menu item.
This appears to be consistent with Joomla routing behaviour. When parsing a URL, Joomla merges the active menu item's query variables with the variables parsed from the route:
Code Select
$active = $this->router->menu->getActive();
if ($active) {
$vars = array_merge($active->query, $vars);
}
Therefore, even if the SEF router removes limitstart=0 from the visible URL, the value can still be supplied through the active menu item and made available to VirtueMart during the request.
This may also explain why the issue appears only in some categories or installations:
- some VirtueMart category menu items already contain limitstart=0,
- older or incomplete menu items may contain only the shortened link,
- categories without a matching menu item cannot benefit from this workaround.
In our case, the store contained approximately 600 VirtueMart category menu items, so opening and saving them manually was not practical.
We applied the workaround directly in the Joomla menu table.
First, we checked which menu items would be affected:
Code Select
SELECT
`id`,
`title`,
`link`
FROM `yourprefix_menu`
WHERE `link` LIKE 'index.php?option=com_virtuemart&view=category%';
Then we appended the missing parameters only when they were not already present:
Code Select
UPDATE `yourprefix_menu`
SET `link` = CONCAT(
`link`,
IF(
`link` NOT LIKE '%virtuemart_manufacturer_id=%',
'&virtuemart_manufacturer_id=0',
''
),
IF(
`link` NOT LIKE '%virtuemart_manufacturercategories_id=%',
'&virtuemart_manufacturercategories_id=0',
''
),
IF(
`link` NOT LIKE '%clearCart=%',
'&clearCart=0',
''
),
IF(
`link` NOT LIKE '%limitstart=%',
'&limitstart=0',
''
)
)
WHERE `link` LIKE 'index.php?option=com_virtuemart&view=category%'
AND `published` = 1;
yourprefix_menu must be replaced with the actual Joomla menu table name, for example:
Code Select
abc_menu
The Joomla #__menu placeholder cannot be used directly in phpMyAdmin.
A database backup should of course be made before running the UPDATE query.
After running the query and clearing the Joomla and VirtueMart caches, the affected categories correctly returned visitors from page 2 or later to page 1.
I did not test whether all the additional zero-value parameters are required individually. For this particular pagination problem, limitstart=0 is clearly the relevant parameter.
The other parameters were added because they matched the complete link generated after opening and saving a VirtueMart category menu item in Joomla.
This database change should still be treated only as a workaround, not as a core fix.
It depends on the request being associated with a matching Joomla menu item. It may not fully cover:
- category URLs opened from external websites,
- bookmarked bare category URLs,
- categories without their own Joomla menu item,
- breadcrumbs using a different menu context,
- manufacturer or search result pagination.
The system plugin proposed above is therefore a broader workaround because it acts directly on the incoming request.
However, the underlying issue should still be fixed in VirtueMart core. A bare category URL should reliably open page 1 instead of inheriting the previous limitstart value stored in the visitor's session.
#50
Virtuemart Development and bug reports / [BUG] Uploading a product imag...
Last post by wyder - July 15, 2026, 18:12:37 PMHello,
I have found a reproducible problem with product image uploads in VirtueMart 4.6.8.
### Environment
* VirtueMart: 4.6.8 build 11258
* Joomla: 5.4.7
* PHP: 8.4.22
### Problem description
When a new product image has the same filename as an image that already exists in the VirtueMart product image directory, VirtueMart overwrites the existing physical file.
This means that uploading an image to one product can unexpectedly replace an image already used by another product.
This is particularly dangerous in stores with many products, because administrators cannot realistically ensure that every uploaded image has a globally unique filename.
### Steps to reproduce
1. Create or edit Product A.
2. Upload an image named: 1.jpg
3. Save Product A.
4. Create or edit Product B.
5. Upload a different image which is also named: 1.jpg
6. Save Product B.
7. Return to Product A or view it on the frontend.
### Actual result
The physical file `1.jpg` is overwritten by the image uploaded to Product B.
As a result, Product A starts displaying the image uploaded for Product B.
The problem occurs without any warning to the administrator.
### Expected result
When `$overwrite` is set to `false` and a file with the same name already exists, VirtueMart should generate and use a unique filename, for example:
1.jpg
17.jpg
173.jpg
The existing physical file should not be overwritten.
### Code analysis
The problem appears to be located in:
administrator/components/com_virtuemart/helpers/vmuploader.php
in the method:
static function checkUploadFile($uploadPath, &$media, $overwrite, &$isimage)
The current code correctly checks whether a file with the same filename already exists:
if(!$overwrite){
$i = 0;
while (file_exists($uploadPath.$mediaPure.'.'.$mediaExtension) and $i<20) {
$mediaPure = $mediaPure.rand(1,9);
$i++;
}
if($i>=20){
vmError('Could not upload file, would overwrite existing '.$media['name']);
return false;
}
}
The loop modifies `$mediaPure` and generates a new filename base.
For example:
1
may be changed to:
17
However, the generated filename is never assigned back to:
$media['name']
The upload is then performed using the original filename:
$uploaded = JFile::upload(
$media['tmp_name'],
$uploadPath.$media['name'],
false,
$trusted
);
At this point, `$media['name']` still contains:
1.jpg
Therefore, the existing file is overwritten even though the collision detection code generated a different value in `$mediaPure`.
### Suggested fix
After the filename collision check and before calling `JFile::upload()`, the generated filename should be assigned back to `$media['name']`:
$media['name'] = $mediaPure.'.'.$mediaExtension;
The corrected code would be:
if(!$overwrite){
$i = 0;
while (file_exists($uploadPath.$mediaPure.'.'.$mediaExtension) and $i<20) {
$mediaPure = $mediaPure.rand(1,9);
$i++;
}
if($i>=20){
vmError('Could not upload file, would overwrite existing '.$media['name']);
return false;
}
}
$media['name'] = $mediaPure.'.'.$mediaExtension;
$uploaded = JFile::upload(
$media['tmp_name'],
$uploadPath.$media['name'],
false,
$trusted
);
Because `$media` is passed by reference:
static function checkUploadFile($uploadPath, &$media, $overwrite, &$isimage)
the corrected filename will also be available later in `uploadFile()`:
$obj->file_name = $media['name'];
and should therefore be saved correctly in the VirtueMart media record.
### Additional information
I checked both:
* the `vmuploader.php` file currently installed on the website,
* the `vmuploader.php` file from the original VirtueMart 4.6.8 installation package.
Both files contain the same code.
Therefore, the issue does not appear to be caused by a modified, incomplete or corrupted installation.
Adding the following line before `JFile::upload()` prevents the existing file from being overwritten:
$media['name'] = $mediaPure.'.'.$mediaExtension;
Could you please confirm whether this is a bug and include the fix in the next VirtueMart release?
Thank you.
I have found a reproducible problem with product image uploads in VirtueMart 4.6.8.
### Environment
* VirtueMart: 4.6.8 build 11258
* Joomla: 5.4.7
* PHP: 8.4.22
### Problem description
When a new product image has the same filename as an image that already exists in the VirtueMart product image directory, VirtueMart overwrites the existing physical file.
This means that uploading an image to one product can unexpectedly replace an image already used by another product.
This is particularly dangerous in stores with many products, because administrators cannot realistically ensure that every uploaded image has a globally unique filename.
### Steps to reproduce
1. Create or edit Product A.
2. Upload an image named: 1.jpg
3. Save Product A.
4. Create or edit Product B.
5. Upload a different image which is also named: 1.jpg
6. Save Product B.
7. Return to Product A or view it on the frontend.
### Actual result
The physical file `1.jpg` is overwritten by the image uploaded to Product B.
As a result, Product A starts displaying the image uploaded for Product B.
The problem occurs without any warning to the administrator.
### Expected result
When `$overwrite` is set to `false` and a file with the same name already exists, VirtueMart should generate and use a unique filename, for example:
1.jpg
17.jpg
173.jpg
The existing physical file should not be overwritten.
### Code analysis
The problem appears to be located in:
administrator/components/com_virtuemart/helpers/vmuploader.php
in the method:
static function checkUploadFile($uploadPath, &$media, $overwrite, &$isimage)
The current code correctly checks whether a file with the same filename already exists:
if(!$overwrite){
$i = 0;
while (file_exists($uploadPath.$mediaPure.'.'.$mediaExtension) and $i<20) {
$mediaPure = $mediaPure.rand(1,9);
$i++;
}
if($i>=20){
vmError('Could not upload file, would overwrite existing '.$media['name']);
return false;
}
}
The loop modifies `$mediaPure` and generates a new filename base.
For example:
1
may be changed to:
17
However, the generated filename is never assigned back to:
$media['name']
The upload is then performed using the original filename:
$uploaded = JFile::upload(
$media['tmp_name'],
$uploadPath.$media['name'],
false,
$trusted
);
At this point, `$media['name']` still contains:
1.jpg
Therefore, the existing file is overwritten even though the collision detection code generated a different value in `$mediaPure`.
### Suggested fix
After the filename collision check and before calling `JFile::upload()`, the generated filename should be assigned back to `$media['name']`:
$media['name'] = $mediaPure.'.'.$mediaExtension;
The corrected code would be:
if(!$overwrite){
$i = 0;
while (file_exists($uploadPath.$mediaPure.'.'.$mediaExtension) and $i<20) {
$mediaPure = $mediaPure.rand(1,9);
$i++;
}
if($i>=20){
vmError('Could not upload file, would overwrite existing '.$media['name']);
return false;
}
}
$media['name'] = $mediaPure.'.'.$mediaExtension;
$uploaded = JFile::upload(
$media['tmp_name'],
$uploadPath.$media['name'],
false,
$trusted
);
Because `$media` is passed by reference:
static function checkUploadFile($uploadPath, &$media, $overwrite, &$isimage)
the corrected filename will also be available later in `uploadFile()`:
$obj->file_name = $media['name'];
and should therefore be saved correctly in the VirtueMart media record.
### Additional information
I checked both:
* the `vmuploader.php` file currently installed on the website,
* the `vmuploader.php` file from the original VirtueMart 4.6.8 installation package.
Both files contain the same code.
Therefore, the issue does not appear to be caused by a modified, incomplete or corrupted installation.
Adding the following line before `JFile::upload()` prevents the existing file from being overwritten:
$media['name'] = $mediaPure.'.'.$mediaExtension;
Could you please confirm whether this is a bug and include the fix in the next VirtueMart release?
Thank you.