| Re: Frustrated |
| by evylrat on 2005/2/24 13:50:12 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. |
| Re: Frustrated |
| by ronhab on 2005/1/27 2:29:57 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.
|
| Re: Frustrated |
| by brash on 2005/1/26 11:58:22 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.
|
| Re: Frustrated |
| by m0nty on 2005/1/25 17:09:24 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.. |
| Re: Frustrated |
| by m0nty on 2005/1/25 16:41:28 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 |
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $15.00 |
| Due Date: | Jul 31 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $15.00 |
|
|