Quote:

Indeed, there are many implications of the word....

Quote:

Yes, I would definitely agree with that.

Quote:

I agree that they do not have an obligation per se, certainly not in a legal sense.

But I think it's somewhat disingenuous to suggest that the fact you don't pay hundreds of dollars for XOOPS makes a significant difference. The license agreements of 99% of commerercial software clearly state that they take no responsibility for data loss, damage, or any screwup to your system caused by their software. It's one of the big differences between software engineering and other engineering disciplines: if the bridge falls down, the engineer is on the hook, but if the software fries your machine, too bad, so sad for you.

I don't want to get into a debate about whether or not that is a fair difference between software engineering and other types of engineering, I just want to point out that open-source software and commercial software are not so different in this respect.

I think the overall professionalism of the XOOPS project has created an expectation on the part of the users. Just as you expect that, because they are a reputable company, Valve will fix the sound stuttering problem in Half Life 2, even though they don't have to, I think it's fair to expect that the XOOPS team will deal with the block problems in 2.0.9.x, because XOOPS is a reputable project.

I guess another way to put it would be: I agree that the XOOPS team is not obliged to fix the problem (and no one should jump up and down demanding they do), but I expect, reasonably I think, that the XOOPS team will make software releases from time to time, each one improving on previous releases in whatever ways they think is best. And I expect that they will think it's best to fix this problem, so I expect that they will fix this problem.

And let's be clear: they *are* working on the problem and I absolutely believe they will fix it -- I'm not suggesting that they're not doing this and I think they should and they're wrong for doing whatever they're doing. I just think it follows from the track record and the reputation of the XOOPS project that they would deal with this, and so it's okay for users to expect that they will deal with it.

But I take your point that it would be crossing a line to suggest that users *have a right* to expect the XOOPS team will fix this. That is an important point.

Quote:

I think your position here is more than fair to such an individual! However, if you released a patch for AMS that somehow screwed up the display of articles on the front page of people's sites, I am sure you would race to fix the problem, and wouldn't it be fair of your users to expect that you would fix the problem?

Quote:

Yes, but see my point above about commercial license agreements. The material below is from the end-user license for MS Word 2000:

Quote:

So they're saying that you have a right to expect the documentation will more or less accurately describe what the software does. Whoppie! And you don't have a right to expect much else:

Quote:

Check any other commercial software license, they're basically all the same. And note the similarities between the wording of the GPL and the Microsoft license, in terms of implied warranties. Coincidence? Nope. Both licenses simply use standard legal wording to cover the asses of the developers.

Paying for your software entitles you to nothing special, it's just a different way of funding development than the open-source model. I don't think anyone should suggest that there's a fundamental difference between what you should expect from a commercial versus an open-source product. All you can expect is whatever the reputation of the company or project leads you to believe.

--Julian

Quote:

Thank you mOnty.

I am sure I could have come to a clear conclusion about this myself if I had followed along more closely with all the releases, patches and comments about them.

But once I sensed there was a problem with 2.0.9, I just steered clear and thought I'd come back when the dust settled. The thing is, while it was pretty clear from what was going on (several patches all at once) that here was something really wrong, there was no clear announcement once the dust had settled.

--Julian

Quote:

I went through all your steps monty with some success, but more non-improvement (I think).

I now have:
1. A template set that does not appear in red in all the spots (good)
2. Blocks that still don't update (no improvement)
3. Blocks that still reverted to showing (empty or 0) for show XX number of posts, forcing me to go in and reset them to 10 so 3000+ comments don't show up on my pages (no improvement)
4. Still had duplicate blocks. However I went in to the DB, searched for the block titles (main menu, recent links) etc. and removed the dupes. So far they haven't reappeared as dupes, but they may. However, when doing this I noticed something that may help track this down. The dupes were identical in the DB, except for one field, BLOCK TYPE. For each dupe, there was a block with block type S (which I assume stands for system) and block type M. I deleted the block type M dupes. Perhaps this is a clue as to what is causing the bug. (no improvement but fixed manually).

So, I guess we have made a little progress. No idea what to try now. (Download a full 2.0.9.2 and do a mass replace via FTP for the whole site?)

Thank you for your help.

hmmm, well u could try also emptying the newblocks & block_module_link tables aswell (or remove duplicated) but when doing that method (do this at the same time as u empty the tpl tables), all your blocks will lose permissions.. so you'll need to go back to admin and update modules again etc, then goto blocks and turn them back on for each page etc.. you'll also need to configure the blocks again.. so it's not a fast track method..

if u leave a browser window logged into XOOPS admin then it'll make things easier.. as logging in afterwards you will have no blocks visible.. so you'll have to user the yourdomain.com/user.php link to login otherwise..

with leaving a browser window logged in already you can simply then go straight to modules and update them all, and then goto groups and blocks and enable them there again..

on both these methods tho it is WISE to BACKUP before doing it in case anything does go wrong.. (i'll indemnify myself here by saying: do it at your own risk!) if u make a backup of those tables 1st then it's easily recoverable..


S in block type means 'System'
M means it's a module Type

there's an sql query that deals with duplicated rows..

maybe some1 here can see if they can turn this into a full query relating to newblocks, block_module_lin, tplfile, & tplsource so that a query can be made to do it all at once..

see this article > http://www.databasejournal.com/features/mysql/article.php/10897_2201621_1

i'll have a go at it, but my sql isn't all that great..

Well this thread certainly got up and going while I was away

Quote:

Good point about the damage already been done as soon as you upgrade. However, I thought the Santy worm exploited a vunrability specfically in the phpbb forum, and therefore wouldn't apply to Xoops? Besides, from the small amount I've read it appears to be an SQL injection attack, and even if XOOPS was vunrable couldn't you minimise your vunrability substaintially by just using something like GIJOE's protector module that has SQL injection attack defense?


Quote:

You've obviously put a great deal of work into your site Ronhab, and after looking at it I can certainly understand your position. Still, if it were me I would think there would be a good deal less risk/work in getting someone to correct the problems rather than shift to another CMS, especially when there are no garantees that you won't suffer similar set backs there. As for the security issue, if you are referring to the Santy worm, please reffer to my question above.

Quote:

I do think that if anyones it is the XOOPS core dev teams responsibility to make fixes for these sorts of things, and I wasn't meaning to suggest that it should be otherwise. However, even though I'm sure those effected would have loved (and probably should have been provided) a more definitive response from the core team, I don't think anyone one but them (the core team) have any place in saying what priority a task is given. They are giving there time, it is at theirs to do with what they will. Besides, even though there is no doubt that this is a show stopper bug for thos effected, it cannot be classed as a major bug (certainly not critical) when it effects such a small proportion of users overall. Definately a bug, and one needing to be fixed, but just not a major/critical one when it is only effecting at most a hundred out of a user base of ten's of thousands. Having said that though I'd be more than happy to try and help you try and solve your problems.


@ jegelstaff

Agree with everything you've said (and the way you've said it) . Also make some good points from angles I hadn't given a lot of thought. I suppose I just get a little defensive of the XOOPS core team, as the name suggests, they are the core of what is driving XOOPS forward. Even though it isn't desirable, loosing 100 XOOPS end users isn't going to impact the XOOPS community a great deal. Loose a handful of the XOOPS core dev team, and we certainly will. I guess I am coming from the angle of wanting to make 100% sure that they (the core team) know at ALL times that the contribution of their time and skill is totally appreciated, and in no way taken for granted.

Hey Brash,

I appreciate very much all the work done by the XOOPS team or I wouldn't be here for so long. I started on PHP-nuke, realized it wasn't up to par and did a lot of research before settling on XOOPS as the best. It will take a long time to migrate my site, so I am jus trying to run in parallel for now and hoping this gets sorted out. I am going to try m0nty's new suggestion over the weekend and see if I can fix the remaining issues by emptying the additional tables. (after backing up!)

I understand being protective of the devs, but I also believe in being fair to all sides and not downplaying something based on what it may impact. I am not saying one is right and one is wrong, that is just how I operate. It may indeed ruffle feathers.

As for being vuln to Santy, I don't believe XOOPS was to the original worm which just did phpbb, but later variants attacked a more general PHP vuln/coding insecurity that we were. At least that is what I thought when I saw the patch come out shortly after it appeared (which is why I upgraded in the first place). Ironic if I upgraded for no reason.

As for the number of sites affected, I dunno. But I have a strong suspicion that many of the recent posts (and there have been many) of people reporting blocks disappearing, not updating, etc. are all related to this same issue. There is something awry with updating/installing modules and it impacting the blocks/templates. I think it remains in 2.0.9.2 as well, since I don't think everyone who is having issues with various blocks all upgraded to 2.0.9. Not 100% sure, just an educated feeling based on years of troubleshooting. Perhaps a dev knows if a change was made somewhere in the process that takes place when that module install/update icon is pushed.

As a side note, in my current state, my tempates aren't red anymore, but if I download my template set, and upload it, the links and system turn red. If I do the same with the default template set, wf-downloads turns red. Two different template sets, both not functioning 100%, but in different places. Perplexing. But my site is at least 90% working now. What is left that is broken is manageable for now and hopefully will get better after the "stage 2".

I will let you know how "stage 2" goes and how I make out. Thanks for helping out.

Is there any news of a fix? Editing the database seemed to remove the duplicate templates, but not the blocks. I use a template set anyway, so I've just deleted the excess ones, so now the number of blocks/templates is red.