upgrade from 3.8.6 to 3.9 causes classes duplicate attribute

Author Message

Softriva .com

Thursday 22 February 2007 10:24:09 am

I have upgraded from 3.8.6 to 3.9 and after I finished I tried to edit my classes but unfortunately I got an error saying when I try to save the classes even if I don't change anything

attribute 'description': (239) duplicate attribute placement'

The is for all classes. What is weird is that no all attributes are duplicates

kracker (the)

Thursday 22 February 2007 11:14:17 am

I too have seen this issue.

For me it was a symptom of a corrupted database (after the upgrade)

I believe there is also a bug associated with a user error durring the upgrade may cause this problem.

I remember a few threads on this subject upon the 3.9 first releases

Anyone else?

//kracker

<i>KMK - Do The Math ...</i>

Member since: 2001.07.13 || http://ezpedia.se7enx.com/

Softriva .com

Thursday 22 February 2007 11:18:00 am

I could not find any previous posts. I would like to see them. What should I search for?

Also, my classes are already translated. Do I have to run the updateclasstranslations.php because I think it is the one causing the problem

kracker (the)

Thursday 22 February 2007 11:25:33 am

Well,

While what most of what I was saying was generic,
part of my reference to other threads was surrounding
this topic, though now upon more thought I'm no longer
certain of the connection between the two thoughts.

See the links in the comments,
http://ez.no/community/contribs/hacks/fix_class_translations

Update: In any case I would dump your current database to a backup, reset the database to your last good backup of 3.8.6 and upgrade the site again, this time I would urge you to go a bit slower and make certain you are performing each step completely before moving on to the next step... I think above all this was my solution to these problems.

//kracker

<i>Home Movies - Jazz Fight</i>

Member since: 2001.07.13 || http://ezpedia.se7enx.com/

Softriva .com

Thursday 22 February 2007 7:45:07 pm

I found out that the problem is not from the updateclasstranslation.php. It happens after I upgrade the database.

Can someone point me to the right direction to troubleshooting this problem?

Softriva .com

Friday 23 February 2007 9:54:29 am

I kinda figured out my problem.

the problem was in my admin siteaccess (codg)_admin) which I have been copying from previous sites every upgrade since 3.8.4.

When I used the admin siteaccess that came with 3.9 everything worked ok.

I think the upgrade procedure need to be looked at since the old admin siteaccesses might not work with 3.9.

It has been long two days trying to figure out what is going on.

Matthew Carroll

Monday 12 March 2007 12:49:07 am

I just confirmed this fix.

I have no idea why, but something in the old admin siteaccess settings was causing this bug for me too. Unfortunately I don't have time to track down exactly which setting at the moment. Removing the entire contents of settings/siteaccess/(mysite)-admin/ and replacing with a copy of the generic settings/siteaccess/admin and re-entering database connection settings solved this. Weird!

Matthew

http://carroll.org.uk

kracker (the)

Monday 12 March 2007 1:46:30 am

Thanks Matthew!

<i>//kracker</i>

<b>Atmosphere - Seven's Travels ... - Trying to Find A Balance</b>

Member since: 2001.07.13 || http://ezpedia.se7enx.com/

Softriva .com

Monday 12 March 2007 7:38:43 am

I did not confirm this yet but I think the problem is from the new attribute sorting boxes added to the class edit tpl. The problem can be duplicated if you use a number twice ie putting attribute sorting number for example 1 in two different attributes.

ahh, hard to explain and I can't upload an image that show the fields. Sorry if not clear.

OOzy

Matthew Carroll

Thursday 03 May 2007 4:17:40 pm

Yep, it is the sorting boxes. I just ran into the issue again, and realised it was because I had the xajax-classattributes extension activated (which overrides the template that was upgraded in 3.9 to include the sort-order boxes). Consequently no data is submitted for the order, and ezpublish chokes. Deactivating that extension must have been the side-effect of creating a fresh admin interface installation that I confirmed as being the solution before.

Matthew

http://carroll.org.uk

Kristof Coomans

Thursday 03 May 2007 11:30:46 pm

Hi Matthew

xajax_classattributes has been updated a while ago to be compatible with 3.9. If you still want to use it then check out the svn version ;-)

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Matthew Carroll

Friday 04 May 2007 2:58:19 pm

Thanks Kristof, I thought it was probably the case that you already updated the xajax-classattributes, but I didn't realise that version incompatibility was the root cause of the problem before. I'll grab the latest.

http://carroll.org.uk

Kristof Coomans

Saturday 05 May 2007 12:10:31 am

It's something that eZ publish really misses: version checks on the extensions. To my opinion, we should have a system similar to Mozilla Firefox, where incompatible add-ons are disabled (of course you can disable this behavior with a setting). I also have been thinking about automatic updates of extensions a long time but this is not something I want to start coding without sponsoring :-)

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Iain MacLean

Thursday 12 March 2009 1:35:34 am

I've only just struck this problem in version 4.0.0, and it seems that it was caused (in my case) by an old version of the file /design/admin/templates/class/edit.tpl. I have been copying all the files from a custom admin site access from one version to the next (like many of us, I guess) and not keeping up with changes in the templates.

I had initially replaced all the config files in the /settings/siteaccess/<custom_admin> folder, and inserted all the customisations I had previous made, as Matthew and "Softriva" discussed above. But, when I changed the SiteDesign in site.ini.append.php to the custom site access design the problem came back.

I then replaced all the templates in the custom admin site access design folder - apart from the override ones - with the new ones that came with version 4.0.0 and that appears to have fixed it. I was able to add a new attribute to a class without the error messages.

I do not have the xajax-classattributes extension installed.

Cheers

Iain

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.

eZ debug

Timing: Jan 31 2025 06:19:22
Script start
Timing: Jan 31 2025 06:19:22
Module start 'layout'
Timing: Jan 31 2025 06:19:22
Module start 'content'
Timing: Jan 31 2025 06:19:22
Module end 'content'
Timing: Jan 31 2025 06:19:22
Script end

Main resources:

Total runtime0.0142 sec
Peak memory usage2,048.0000 KB
Database Queries3

Timing points:

CheckpointStart (sec)Duration (sec)Memory at start (KB)Memory used (KB)
Script start 0.00000.0050 588.3906151.2422
Module start 'layout' 0.00500.0021 739.632836.7109
Module start 'content' 0.00710.0056 776.3438110.3438
Module end 'content' 0.01270.0015 886.687549.9922
Script end 0.0142  936.6797 

Time accumulators:

 Accumulator Duration (sec) Duration (%) Count Average (sec)
Ini load
Load cache0.002316.3127140.0002
Check MTime0.00107.3400140.0001
Mysql Total
Database connection0.00074.990010.0007
Mysqli_queries0.002215.578530.0007
Looping result0.00000.063710.0000
Template Total0.00118.010.0011
Template load0.00096.305810.0009
Template processing0.00021.694610.0002
Override
Cache load0.00064.529110.0006
General
dbfile0.001510.544980.0002
String conversion0.00000.041940.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

UsageRequested templateTemplateTemplate loadedEditOverride
1print_pagelayout.tpl<No override>extension/community/design/community/templates/print_pagelayout.tplEdit templateOverride template
 Number of times templates used: 1
 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs