Bug #8894
Article prices get stored wrong way in DB
| Status: | Closed | Start date: | 2010-07-15 | |
|---|---|---|---|---|
| Priority: | Must have | Due date: | ||
| Assignee: | Ingo Schmitt | % Done: | 100% |
|
| Category: | - | Spent time: | 1.00 hour | |
| Target version: | 0.12.x | Estimated time: | 3.00 hours | |
| Votes: | 0 |
Description
Hi,
seems like prices get stored wrong way in the database under some circumstances (TYPO3 4.3.3 with multi-tree-setup here).
The prices are stored in tx_commerce_article_prices with an empty field fe_group. Thus all products appear to have price "0" in frontend. If I change fe_group to "0" in database table, all prices are rendered correctly...
Associated revisions
- Fixed #8894 Article prices get stored wrong way in DB (Thanks to Michael Knabe)
- Fixed #13334 Remove split and ereg calls (see #11922 and #11921)
- Fixed #11921 Problem at checkout (php 5.3) with spliti in class.tx_comerce_div.php (Thanks to Jochen Biedermann)
- Fixed #11922 Problem with Checkout (PH 5.3) with eregi in class.tx_commerce_pi3 (Thanks to Simon Schick)
- Fixed #8894 Article prices get stored wrong way in DB (Thanks to Michael Knabe)
- Fixed #13334 Remove split and ereg calls (see #11922 and #11921)
- Fixed #11921 Problem at checkout (php 5.3) with spliti in class.tx_comerce_div.php (Thanks to Jochen Biedermann)
- Fixed #11922 Problem with Checkout (PH 5.3) with eregi in class.tx_commerce_pi3 (Thanks to Simon Schick)
History
Updated by internezzo ag almost 3 years ago
we have the same problem with the newest svn version
Updated by Frank Mey almost 3 years ago
Here is a small php-workaround-script that updates the corresponding data tables using the fe_group (in my case: 0 is inserted, so all fields can be seen by all FE-Users resp. UserGroup-ID 0):
<?php
mysql_connect('localhost','<yourusername>','<yourpasswort') or die('DB Connect ERROR');
mysql_select_db('<yourdatabase>') or die('No database selected');
$arrTables = array("tx_commerce_attributes", "tx_commerce_categories", "tx_commerce_products", "tx_commerce_articles", "tx_commerce_article_prices");
$lauf = 0;
while ($lauf < 5) {
$strSQL = 'UPDATE '.$arrTables[$lauf].' SET fe_group="0"';
$res = mysql_query($strSQL);
if ($res == true) {
echo('Table '.$arrTables[$lauf].' updated. <br />');
}
$lauf++;
// else die('Kein Resultat aus DB erhalten');
}
?>
I run this per cronjob every 5 minutes - very quick and dirty, but keeps store working...
Updated by Morten Haggren almost 3 years ago
Actually the prices arent stored wrong in the db ( going by how the rest of typo3 handles fe_group access ),
a fix for this error
lib/class.tx_commerce_db_article.php@134-140
if ($GLOBALS['TYPO3_DB']->sql_num_rows($result)>0){
while ($return_data=$GLOBALS['TYPO3_DB']->sql_fetch_assoc($result)){
$price_uid_list[$return_data['fe_group']][]=$return_data['uid'];
}
$GLOBALS['TYPO3_DB']->sql_free_result($result);
return $price_uid_list;
}else{
Changed into
if ($GLOBALS['TYPO3_DB']->sql_num_rows($result)>0){
while ($return_data=$GLOBALS['TYPO3_DB']->sql_fetch_assoc($result)){
if ( $return_data['fe_group'] == '' ) { $return_data['fe_group'] = 0; }
$price_uid_list[$return_data['fe_group']][]=$return_data['uid'];
}
$GLOBALS['TYPO3_DB']->sql_free_result($result);
return $price_uid_list;
}else{
fixes atleast this problem.
Updated by Ingo Schmitt almost 3 years ago
- File patch-8894.txt added
- Assignee set to Ingo Schmitt
- % Done changed from 0 to 40
- Estimated time set to 3.00
See attached patch
Updated by Stefan Völker almost 3 years ago
Unfortunately this patch didn't work in my setup (no multitree, simple 4.4.2 installation, TemplaVoila, ods_commerce_delivery).
"fe_groups" still gets an empty value after saving the article in the backend.
Any more hints ?
Updated by Manfred Mirsch over 2 years ago
I solved the problem with this code in "ext_tables.php" in my own extension:
t3lib_div::loadTCA('tx_commerce_article_prices');
$TCA['tx_commerce_article_prices']['columns']['fe_group']['config']['default'] = 0;
Greetings,
Manfred Mirsch
Updated by aZatilla over 2 years ago
Stefan Völker wrote:
Unfortunately this patch didn't work in my setup (no multitree, simple 4.4.2 installation, TemplaVoila, ods_commerce_delivery).
"fe_groups" still gets an empty value after saving the article in the backend.
Any more hints ?
Just change with phpmyadmin the Database field type to Integer, and default 0
Updated by Robert Grede over 2 years ago
simply change tx_commerce_article_prices in ext_tables.sql:
fe_group varchar(100) DEFAULT '0' NOT NULL,
to:
fe_group int(11) DEFAULT '0' NOT NULL,
This was the way in previous releases too.
Updated by Sascha Egerer over 2 years ago
Robert Grede wrote:
simply change tx_commerce_article_prices in ext_tables.sql:
fe_group varchar(100) DEFAULT '0' NOT NULL, to: fe_group int(11) DEFAULT '0' NOT NULL,
This was the way in previous releases too.
int is the wrong field type here because you need a comma seperated list of integers
Updated by Michael Knabe over 2 years ago
- File com_8894_v2.diff added
The bug is not the empty fe_groups field but how commerce is not able of handling the empty field. And although it is not the cleanest solution to set the value to 0 while getting the prices (clean solution would be to fix all the places that depend on the 0) it is the solution with best cost-performance ratio.
So my +1 for Morten patch with CGL fixed. Being the nice guy that I am I attached a clean version.
@Stefan Völker: Did you test if the prices work with the patch or did you only check for the database value?
Updated by Karsten Dambekalns over 2 years ago
I just applied this patch and it fixed an issue with prices being displayed as 0 on the FE.
Updated by Benny Schimmer over 2 years ago
- Status changed from New to Closed