Yep, definately not a good place to be in. XOOPS 2.0.9.2 was released on th 31st of last month, so it's been in the wild for coming on four full weeks now. As a user you really have 5 options;

1) Actively try and track down the problems yourself

2) Stay on, or roll back to 2.0.7.3

3) Log Bug report at sourceforge and wait for something to happen

4) Pay a developer to find and fix the problem

5) Move to another CMS


Obviously number 4 & 5 are quite extreme considering XOOPS 2.0.7.3 is perfectly functional. So going to these lengths sort of border being on going over the top. To my understanding the biggest reason for upgrading to 2.0.9.2 would be for PHP5 support, other than that what is really driving the need to upgrade in such a hurry?

One observation I have made is that everyone (bar a few) who are reporting these bugs is doing so with what seems to be an expectation for someone else to fix it for them (i.e XOOPS core team). Not everyone is a developer, but that doesn't mean that you shouldn't at least try and track down the problems yourself. It's a pretty safe bet that everyone here has a computer at home, which also means there should be possible to setup your own testing environment. Switch things about, document your environment and changes you've made. The work needed to be done by the core team would be greatly reduced if we were able to give them more information other than it doesn't work. This is not a critisim, and I have no doubt that 99.99% of Xoopers are very concious and very appreciateive of the work the core team put in. I just think as a group, we as end user could be doing a lot more to help these guys out.

Brash you have some very valid options and opinions there but i must disagree in the fact that we should try to fix a problem that was not incurred by us (the site owner) in the 1st place.

I do respect and understand that with any program be it software or CMS orientated there are always bugs but in saying that the core development team have taken on the responsibility and the position to develop this CMS further so in turn any bugs that incur during that time should be fixed by the core development team.

If a non developer has a fix for it thats even better and even more helpful to the core development team and yes I support the idea that the members become more involved and independent in fixing problems, but not everybody on here including myself are PHP programmers or have a strong idea on how it works I have tried I have read a lot about it but its something that I personally find difficult to understand as well as some on here.

And finally this is a SUPPORT FORUM where people like me (dummies) can come and get help for things we need help with I do not simply post stuff down if I know how to fix it what would be the point I post stuff here that i do not have any idea how to fix after I have tried myself to do what i can.

So brash please there is no need to be critical on us non php programmers or newbies because we ask to be helped out and are asking for something that should of been done beofore the final release.

As for the roll back to 2.0.7.3 I would love to roll back to that version if I knew how to I have a idea that i just back up the database and then simply overwrite all the files i have with the 2.0.7.3 core files is that correct?

regards
kiwiguy

But even with the rollback, if it is not a full database restore of before the upgrade, I think the duplicate blocks would still be there.

Mithrandir is on vacation, and he is the one that told me that they were trying to find a safe way to remove the duplicates.

He also mentioned that they were going to take the time to do it right. The bug itself is fixed in 2.0.9.2. But for those of us who upgraded to 2.0.9 was the bugged version. I think the two quick releases after that was to fix the bug and to rollback some changes released in 2.0.9 that was decided to wait until 2.2.

So like I said earlier Draven gave a valid point to fix it manually, which I will look into when I have time to go through the tables and compare to find the common denominator he spoke of.

Right now the workaround that I am using works with not any problems except some red numbers in my cloned templates. I can live with that for awhile.

OH, and 2.0.9 was released with security in mind.

Quote:
This approach simply isn't going to work, and if widely adopted is just going to kill this CMS. There are 26,000 registered XOOPS users here on Xoops.org, plus countless others using it. I don't know the exact number, but there are only around a dozen or so members working in the core team, and not all of those are coders. It's not hard to see that with these numbers, depending solely on the XOOPS core team for fixes for the XOOPS core is not a situation we want to be in (I'm not necessarily talking code contributions here).

We should be working together towards the common goal of making XOOPS better, and not taking a stance of 'you broke it, you fix it'. Imagine if the tables were turned and the support forums had this attitude where users where expected to fix their own problems? It would sound unreasonable and a just a bit plain silly wouldn't it. The XOOPS core team might or might not wear their undies on the outside, but that doesn't make them super heros, they are human just like us, and as such are garanteed to make mistakes. As a community we should be there to aid in the problem resolution where ever we can.

Quote:
Fair comment, but if you step back for a minute and think, it really wouldn't make sense for the XOOPS team to release a version knowing it had serious bugs. With that in mind you'd have to assume that at the time of release no bugs were known to the XOOPS core team, and in turn you can't be expected to fix what you don't know exists. Even so, this bug as big as it may seem still only effects a very small percentage of XOOPS users.

I did a bit of a calculation in another thread regarding 2.0.9.2 issues, and I found that as a user with problems, to download count ratio that only around 0.2% had experienced problems. This is of course making an inaccurate assumption that each download equated to an upgrade of and XOOPS environment, but even if we add in a 10x factor to take this into account, we still only end up with around 2% of people who have upgraded have problems. Just trying to put a bit of perspective on the problem.

Quote:

You don't have to be a PHP programmer to be able to help. If you are able to upload and install Xoops, then you have enough knowledge to be able to have some positive input into moving towards problem resolution. I can't code PHP either. I might be able to hack in a line of code here and there if what I am wanting to do is really obvious, but that's about it. The fact is that that different environments can produce totally different results. For example prior to XOOPS 2.0.7.x XOOPS had a problem with IIS where once you logged in you were returned to the home page rather than being returned to the page you were browsing. This did not happen on Apache. It's feedback on things like this that can trigger ideas amongst the core team (and others)as you might not know why it does it, but giving that feedback that it does do it can be vital.


Quote:

This is true, but just because you have posted a question shouldn't mean you cease seeking the solution yourself. The best you can hope for here is HELP, there should be no expectation of having things done for you, no matter what the question. The only time you are justified in having the expectation of having something done for you (as opposed to someone helping YOU do it) is if you have an mutual agreement with the other party as such (service in exchange for money for example). Again, I am not being critical, just trying to demonstrate ways in which we can all contribute to making XOOPS better, regardless of individual skillset.

Quote:

This is correct, all you should have to do to roll back is restore the database to the backup done prior to the upgrade, and then upload the XOOPS 2.0.7.3 pack over the top.

This is a complicated thread with a lot of valid ideas and opinions, and for the most part I agree with both (all?) sides, to some degree (I don't think there's a fundamental disagreement here, but perhaps a difference of opinion in approach or degree).

I'd like to offer some comments on just one point...

Quote:

I completely support the idea that everyone in the community is capable of (and should be encouraged to) help out however they can. I also agree that non-programmers are capable of more than they realize.

But I think that's the double-edge of this sword: non-programmers often literally do not realize what they can offer, or lack the knowledge necessary to offer it. Detailed information about how or when you run into a problem, plus detailed information about your site setup, OS, PHP version, etc, is often beyond the ability of many users to provide.

However I think it is unreasonable to suggest that the core team is in some kind of equal relationship with posters in the support forums, and everyone has simliar obligations to work at fixes. The core developers are releasing a product for others to use, and there is an implied responsibility there, the lack of warranty notwithstanding, which does not flow in the other direction. End users do have a right to expect something be done for them, namely, that developers fix serious problems that they introduce.

There has been a lot of fantastic features and overall professionalism in the XOOPS project over the last year or so, which make it even more reasonable to expect that upgrades will not actually damage your XOOPS installation. Introduce some bugs, maybe, but this block situation is actually harmful to a site. That is very serious, it's the most serious kind of bug you can ever have. To my knowledge, there has never been so serious a bug in XOOPS.

I made a comment to this effect in a news posting, and it was perhaps harsh of me to do so without saying more. So I'll pipe up here and say that I think the core devs have done and continue to do an amazing job; XOOPS really is reaching a professional level of maturity. But that is why the problem is so serious, in my opinion. A problem of the magnitude of the blocks bug is simply not expected at all from a project that is otherwise so good.

So, especially considering the professionalism that the XOOPS team has exhibited in pretty much every area, I think the "you broke it, you fix it" attitude is completely fair. It's what you would expect of a professional software development effort, and XOOPS has been behaving in a professional way overall.

Sure, the users have a role to play filing bug reports, etc, more so for open-source projects than for commercial ones. But the fundamental responsibility lies with the developers.

I also think the communication effort about this could be better. There has been no prominent explanation of the problem in a news posting. There have been numerous threads discussing problems, and notes in the changelogs for patches that mention problems. But no single explanation.

I think this multipliction of references to the same issue(s) actually makes things seem worse than they are, because there's more chatter in the ether about this stuff than there would be if there were a single point of discussion about them. The current situation unnecessarily propogates FUD (fear, uncertainty and doubt) about 2.0.9.2.

My original training was in journalism, and there is a principle in the press (not always followed!) that if you run a correction, it should be as prominently placed in the newspaper as the original story was. I think that advice holds true for any communication effort: if there's a major problem like this in an upgrade, then some statement about the problem should be made, in the same way that the upgrade itself was announced. In this case, that means a news posting.

I have yet to see a clear statement that the problem only affects users who upgraded from 2.0.7.3 to 2.0.9 or to 2.0.9.1, but not ones who go straight from 2.0.7.3 to 2.0.9.2. I don't even know if that is true, though I think it is from what I've read. That kind of information should be coming from a central, reliable, trusted source, and should be broadcast prominently to the community. That's the kind of thing that eliminates FUD.

Anyway, like I said, I don't think there's a fundamental disagreement going on here. But I do think the overall excellence of the XOOPS project makes this issue stand out in stark contrast.

--Julian

I pretty much agree with everything you said jegelstaff, except for this statement;

Quote:

I think we REALLY need to be careful with our definition of the word "expect".

I think to use it in the terms of we expect a quality release. Meaning nothing other than it would be unusual that the XOOPS core team release a porely coded/tested version, then that is fine.

However, using the word "expect" in terms of we expect quality releases as some kind of right of passage. Meaning that the XOOPS core team have some kind of obligation to you (the end user), in the same manner a professional service that you would be paying anything from a hundred dollars ramping up to tens of thousands a year for, then I think that is a completely unrealistic, not to mention unfair mindset to have.

My viewpoint on this definately straddles both sides of the fence. I'm an end user as far as XOOPS is concerned, so in this regard I share many of the viewpoints of other joe blow XOOPS users. However, on the flipside I also develop AMS with Mith. Knowing how much time and effort I put into AMS of my own spare time, if I had a user with the attitude that they had this right of passage to get the same level of services as if they were paying for it, it'd take me about 3.4 nano seconds to tell them to get stuffed. I know I devote more time during the week where I am working on nothing other than AMS, than time I devote to my own girlfriend. I know nobody asks me to do this, and I do so by my own free will, but regardless to make that sort of commitment in time and effort to then have someone who is giving you NOTHING in return to tell you that in effect your best is not good enough simply does not sit right with me. I don't know what the XOOPS core teams view are, that might have a more tollerant approach than myself.


Just to finish up, I just want to point out a section of the GPL that is included at the top of every single php file in the XOOPS package;
Quote:

Wow, lot of stuff here. I guess this will be a long post.

Quote:
Tried/trying to do so.
Quote:
Doesn't fix, as DB is the issue once you upgrade. Also, leaaves you vulnerable to Santy worm.
Quote: Already done.

Quote: Not an option.
Quote:
What I am in process of doing since that's all that left.

2.0.7.3 has security issues so it isn't an option. It is the reason I upgraded, not becuase of PHP5 support.

Quote:
I don't know which group you are putting me in, but is it unreasonable for someone to expect the core team, when they make a release with a major bug, to then correct that mistake? Everyone makes mistakes. You do. I do. But I don't then go tell people to pound sand. I attempt to 1) apologize, 2) explain what happened 3) work to correct it. I find it astonishing that people think it is OK for the dev team to tell the user base to pound sand and go fix it themselves. If that is really the attitude, than XOOPS has bigger problems than this bug.

I would be happy to help the devs fix this, but there has been zero feedback on what to do. No: Can you try making change X in file Y.php. That makes it hard to fix for a non-coder. Or even for a coder who wasn't involved in the dev process for these upgrades.

My attitude isn't you broke it, you fix it.
It is you broke it, let's get this fixed.
But from the other side all that has been received is "we broke it. Sucks to be you (plural). We'll fix it when we get around to it."

Not good.

After the bug was discovered the dev team worked very hard to fix it so that other people weren't affected. There were a number of quickly released patched (2.0.9.1 and 2.0.9.2) to correct it so other people didn't get hosed. But then BOOM. Nothing. Can't be much of a priority if we can get immediate fixes out within a day, but have nothing happening for four weeks for those who got bitten by the bug.

jegelstaff is absolutely correct. This isn't a tiny little bug, but something that badly breaks a XOOPS site. If we were using a trouble-ticket system, it would be lableled "critical". Yet it sits unresolved, and worse yet, UNASSIGNED in the bug tracker. With little to no feedback from the devs on what, if anything, is being done to correct it.

So here is what I have done:
1. Tried rolling back to a previous version of code
2. Tried regenerating my templates
3. Tried regenerating my blocks
4. Tried cloning my template set
5. Tried downloading and then re-uploading my template set
6. Looked in the database for something that could be corrected. However the templating system spans a number of tables, making it beyond my ability to find anything helpful.
7. Filed a bug on sourceforge
8. Filed a bug here on XOOPS.org
9. Tried a different theme
10. Kicked self in ass for not backing up my DB before patching.

So without any feedback from the devs on what can be tried now, I really don't think there is anything else I can do. If you have a suggestion, I am all ears. If not, then I believe my time is better spent migrating to another CMS than it is banging my head against a wall trying to locate the source of this bug by randmomly firing off in every direction until I hit something.

PS - Conrats on your MVP award brash. It's a good program and alot of fun.
PPS - I don't think anyone else is saying "just fix it for me" either. I could be wrong though.

The Bug was FIXED in 2.0.9.2 the problem was from users who updated 2.0.7.3 - 2.0.9 1st.

the developers are trying to find a way to remove the duplicate templates from the db they have said this MANY times..

but if you want to do it manually, you can, but you will have to redo or upload your custom templates again afterwards..

you can either do it the long way and manually go thru the template tables in your db removing all duplicated content..

or simply do it the quick way..

1. goto XOOPS admin and set in preferences to use 'default' template set..

2. goto phpmyadmin. find table : xoops_tplfile

empty that table completely by removing all entries (don't drop the table)

3. find table : xoops_tplset

remove all templates except for default..

4. find table : xoops_tplsource and do the same.. empty all entries from the table..

now goto XOOPS admincp, goto modules and update each and every module.. (effectively regenerating the templates)

now you should see no duplicate entries in the templates section.. you can then clone and upload your custom templates and re-edit them..

-- lots of manual work, and a bit of work on your side, but your duplicate templates etc should be gone..

Well.... what have i started here i just wanted to share my frustrations and started a major debate... GOOD... It might be time to see some healthy opinions come out..

Still got issues and done everything that was asked apart from paying a programmer or moving CMS (which I am aclose to doing)

And Monty does this fix the affects it has on my wf downloads blocks that does not display properly my recent downloads that are added or is this a totally different issue??

regards
kiwiguy

it will remove all templates completely from the database..

which is y i mention that you will then have to update each module afterwards..

i'm not sure if that will fix the wf-downloads problem you describe, if its thru the duplicated templates problem then it might fix it..

it might also be a good idea afterwards to optimize ur tables as there is likely to be some overheads