$category_id being mangled when editing category

[spork]

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:

Code Select Expand


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:

Code Select Expand


$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...

[spork]

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:

Code Select Expand


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.

[spork]

seriously, anyone?

Can someone at least tell me what "$d" in all these classes is and where it comes from?

[mauri]

Check your db tables _vm_category and _vm_category_xref id:s.
Should be like in attached images.

[attachment cleanup by admin]

[spork]

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?

[mauri]

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?

[spork]

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:

Code Select Expand


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?

[spork]

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:

Code Select Expand


[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.

[mauri]

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

[spork]

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!