I'm stumped on this one. VM 1.1.3, Joomla 1.5.10, php 4.4.9, mysql 5.0.77.
I recently upgraded from phpshop/mambo to joomla/vm. I was poking around the categories and noticed that changes made in the "product.product_category_form" were not sticking. When I turned on joomla's debugging and looked at the SQL I saw that the update query was using an incorrect category_id. It looks like the category_id is getting truncated on the first alpha character in the id.
For example, if the URL looks like this:
http://foo.com/administrator/index.php?option=com_virtuemart&page=product.product_category_form&category_id=3bf6bd755ad339540d364005b2164ee6&category_parent_id=0a5aedd059ad065ed41c2a4d1edce1f7
The category_id becomes "3".
At the top of product.product_category_form.php, there is the following code:
$category_id = vmGet($_REQUEST, 'category_id', 0);
Immediately after that I just echo'd $category_id, and sure enough, it's always truncating at the first non-numeric character.
What could be causing this? I can't imagine I'm the only one who's trying to edit categories in 1.1.3. :) What's weird about my environment? Do newer versions of VM not use that incredibly long hex category_id format?
Thanks...
Bump.
Anyone?
edit: Also found this interesting bug when adding a new category to see if this problem only happened with imported categories (it affects both, btw). Look at the query that Joomla dumped when I added the category:
UPDATE `jos_vm_category`
SET `category_name` = 'Joomla-VirtueMart Test 2',
`category_publish` = 'Y',
`category_description` = 'Test 2',
`category_browsepage` = 'managed',
`products_per_row` = '0',
`category_flypage` = 'flypage-ask.tpl',
`category_thumb_image` = '',
`category_full_image` = '',
`mdate` = '1243887012',
`list_order` = '0'
WHERE category_id=2
AND vendor_id=1
Note the "WHERE" and "AND" clauses are not quoting their criteria. This causes lots of things besides "2" to match, namely everything in the table starting with "2". A side-effect is that the new category shows up about a dozen times. Again, I think "2" is wrong - there's probably supposed to be many more digits after that. So in addition to the URL chopping, that value should probably be quoted as well.
Thanks,
Charles
edit again:
confirmed on a php 5.2.9 host as well.
edit again:
manually setting $category_id in product.product_category_form.php lets me view/edit that category_id, so the problem lies somewhere in vmGet's parsing of the URL it seems.
and another:
$_REQUEST contains the truncated category_id, $_GET has the correct one. php.ini has standard variable order (ie: GPCS). The plot thickens. I'm seeing this behavior throughout the category tree - it happens with edits, deletes, etc. This is quite the rabbit hole. Hopefully some poor chump will stumble across this thread in the future and get something out of it. :)
seriously, anyone?
Can someone at least tell me what "$d" in all these classes is and where it comes from?
Check your db tables _vm_category and _vm_category_xref id:s.
Should be like in attached images.
[attachment cleanup by admin]
I can tell you one thing that's very different. Your category ids are way different than mine. What version did you start with? Mine is a phpshop upgrade and the ids are long strings. Perhaps VM is just not able to deal with the old category_ids?
Something is wrong in your upgrade. I remember(it´s a long time) mambo-phpShop and the ids was like 1,2,3,4,5,6,....
Have you copy your original phpshop files and db?
Quote from: mauri on June 07, 2009, 14:00:36 PM
Something is wrong in your upgrade. I remember(it´s a long time) mambo-phpShop and the ids was like 1,2,3,4,5,6,....
Have you copy your original phpshop files and db?
I still have the original db. The ids are long hex strings in there as well:
mysql> select category_id, category_name from mos_pshop_category;
+----------------------------------+------------------------+
| category_id | category_name |
+----------------------------------+------------------------+
| eb72c3b0434fcc5e8dfd0c29da54fba1 | Professional Makeup |
| ec940f375ea417becedf2c1968ffb7a2 | Makeup |
| 68e33576afe516083d0b3d22627697f8 | Tools & Accessories |
| a54ae16e7f909a18c857b1e2de316e3f | Skin Care & Anti-Aging |
| 41ac3e8e08e3d0410302218b3db8f5c7 | Blush |
| 1323d22c9e47c27f47d65103987d10b7 | Bronzers |
| 24f2f54145e29e3df4b4e19f07a23ab4 | Matte Eye Shadows |
| 8360d853b52647ff376b0e226435b84e | Eye Pencils |
I've seen the same in Googling around on this issue as well.
If at some point the numbering scheme changed, I couldn't find any note of it in the various changelogs. I manually stepped through the sql updates and never saw anything that would transform the category_id field. Just grepped through the sql update files again and didn't see anything that alters that table in such a grand fashion.
My next step is to alter the php config for this virthost so that php takes GET and POST before Cookies, ie: "CGPS" rather than "GPCS". If that fixes it then I just have to assume something's totally borked in how VM is passing the category around. It's always truncating it in $_REQUEST but not in $_GET. If the IDs changed to no longer have alpha characters, then perhaps that's being filtered somewhere in the guts of VM...
Is there a forum here somewhere where I can get a definitive answer on when the id field changed, or if it has changed?
In the old mambo install, I can see the id being created as a hash:
classes/ps_product_category.php: $category_id = md5(uniqid($hash_secret));
I'll see if I can dig up the commit history on that file.
edit: nope, the source repository does not go back far enough. I do see at some point "category_id" became "auto-increment", which it was not in my version of mambo-phpshop. So there was a change, but the upgrade procedure does not address it.
Actually, here it is, from sourceforge:
http://mambo-phpshop.cvs.sourceforge.net/viewvc/mambo-phpshop/mambo-phpShop/classes/ps_product_category.php?r1=1.20&r2=1.21
That's where the category_id change was made from a hashed value to just an auto-increment field in the db. This is likely my problem. I suppose I can convert all my category_ids... What a pain. That's probably why the upgrade doesn't do it - a royal pain in the arse getting the child/parent stuff updated as well. blech.
Can I call this a bug? If so, how to report?
OK - So I went through and changed all my ids in the category table and the category_xref table to be simple digits. All is well.
I'd ask that if any developers look at this you consider noting this somewhere in the upgrade guides, and perhaps do a check when doing an automated upgrade.
In short, if you're running an older (and supported for upgrade) version of mambo-phpshop, your categories will not import correctly. There seem to be two ways to rectify this:
-Before upgrading, instruct the user how to do a bulk replace in the db. I don't know how to automate this, I just made a quick shell script that spit out a bunch of updates for the jos_vm_category and jos_vm_category_xref tables (see below).
-Find the change that was made somewhere in VM (likely recently) that is filtering the session data in a way that only allows [0-9] in the category_id field and back it out or loosen it up a little. This would allow upgraders to not have to modify their category ids.
My script basically spit out a bunch of sql statements like this:
[spork@php4 ~/html/muc]$ COUNT=1; for i in `cat /tmp/muc-cats-tran `; do echo "UPDATE xxx SET category_id='$COUNT' where category_id='$i'"; COUNT=`expr "$COUNT" "+" "1"`; done
Resulting in something like this, altered for each table. The file "/tmp/muc-cats-tran" is just a dump of all category_ids:
UPDATE jos_vm_category SET category_id='1' where category_id='08a2956fa353ef08f41dc365826b515e'
UPDATE jos_vm_category SET category_id='2' where category_id='090aaa8f37baf4531345d85d3adb1484'
and
UPDATE jos_vm_category_xref SET category_parent_id='1' where category_parent_id='08a2956fa353ef08f41dc365826b515e'
UPDATE jos_vm_category_xref SET category_parent_id='2' where category_parent_id='090aaa8f37baf4531345d85d3adb1484''
and
UPDATE jos_vm_category_xref SET category_child_id='1' where category_parent_id='08a2956fa353ef08f41dc365826b515e'
UPDATE jos_vm_category_xref SET category_child_id='2' where category_parent_id='090aaa8f37baf4531345d85d3adb1484''
Hopefully that will help someone out.
You was right. I find this old phpshop update.
#############################################
# SQL update script for upgrading
# from phpshop package 1.2 RC2 to 1.2 stable
#
# !!! IMPORTANT NOTE !!!!
# The Field Types for all occurences of category_id have been changed from VARCHAR to INT.
# PROBLEM: It's NOT possible to update your existing Category IDs
# just by this SQL File.
# You will have to use the Link
# >> UPDATE FROM 1.2 RC2b <<
# on the Installation Screen ("Installation was sucessful .. bla")
# Therefore you must copy the file installation.php into the directory
# /administrator/components/com_phpshop/
#
#############################################
# 14.02.2005
Ah. I think that my first problem was that I had something in between those two releases - something that the original admin had grabbed way back when that's no longer even listed on sourceforge. I also did the upgrade manually, so whatever magic the updater would have done was not done. I went the manual route since I didn't seem to fit into either case presented by the updater.
Thanks!