I'm sure most of you will be aware that GiJoe is seriously thinking, or indeed may have decided, to drop support because on an issue with compatibility with his modules?
This was modified several releases ago, and causes a compatibility issue with his modules.
Because of this, a new version was included in the "extras" folder. Indeed, an explanation of this has also been included in the release notes for the last few versions.
GiJoe has submitted a fix on his site, which works similar to the one in the "extras" folder...
To prevent the loss of a major module and utility contributor... can we seriously consider reverting to this version of the code... and perhaps swapping the current one to "extras" .... at least until this issue can be solved properly?
If we have another release... if any other errors are found... this could be done there... or simply a request for people to replace this piece of code to enable his modules to work correctly... and a modification of the current release?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
guys, it's time to listen to community. If we are many to post here, it's to help and to prevent disasters, not to flame. The first alert dealed with GIJOE. The second with the need of further testing before releasing (http://sourceforge.net/forum/message.php?msg_id=4484560). The third with the need to secure code urgently.
Moreover, I really hope that next release will have a due public RC stage, instead of close testing.
marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was not aware of all this before yesterday when a user reported this in our skype room. I investigated the problem and was on the impression that the resosurce.db.php we had in our extra folder was addressing this issue. I posted this on Gijoe's web site. The thread is there :
So my opinion is that the changes introduced by Skalpa in the template system of 2.0.14 are good :
-- Try to read /themes/(your_theme)/modules/(dirname)/(templates) first. (1)
-- Try to read /modules/(dirname)/templates/(templates) second. (2)
This causes problem for module that do not have their templates in modules/(dirname)/templates/. So Gijoe is proposing as an alternative, to add another ELSE after those 2 verification :
-- Else read DB template ... (3)
Which makes sense to me. Everyone will be happy.
So my sugestion :
1- Wwe make an offical statement that in order to support some module, you can use this new resource.db.php, to inform people
2- If we need to publish a 2.0.17 for an important bug, then we include this new resource.db.php
Here are my 5 cents. What do you guys think ?
Cheers !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
[quote]
1- We make an offical statement that in order to support some module, you can use this new resource.db.php, to inform people
2- If we need to publish a 2.0.17 for an important bug, then we include this new resource.db.php [/quote]
I think you meant 2.0.18? Anyway, yes, it makes sense to me as well. I encourage the official statement to be as clear and easily found as possible, including a note on the Download XOOPS page of xoops.org. This was a problem with a bug in 2.0.15 that could only be fixed by downloading one extra file and for a long time, there was zero indication when you downloaded XOOPS from xoops.org that you also needed this other file.
Thank you for taking the time to investigate and clarify this Marc!
--Julian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sure most of you will be aware that GiJoe is seriously thinking, or indeed may have decided, to drop support because on an issue with compatibility with his modules?
(see this thread: http://www.xoops.org/modules/newbb/viewtopic.php?topic_id=60594 and http://xoops.peak.ne.jp/md/d3forum/index.php?post_id=9650)
The issue is with the resource.db.php file
This was modified several releases ago, and causes a compatibility issue with his modules.
Because of this, a new version was included in the "extras" folder. Indeed, an explanation of this has also been included in the release notes for the last few versions.
GiJoe has submitted a fix on his site, which works similar to the one in the "extras" folder...
To prevent the loss of a major module and utility contributor... can we seriously consider reverting to this version of the code... and perhaps swapping the current one to "extras" .... at least until this issue can be solved properly?
If we have another release... if any other errors are found... this could be done there... or simply a request for people to replace this piece of code to enable his modules to work correctly... and a modification of the current release?
<<I was not aware of all this before yesterday when a user reported this in our skype room.
come on, guys, you simply have ignored reminders, dont' lie:
. http://sourceforge.net/forum/message.php?msg_id=4472013
. http://sourceforge.net/forum/message.php?msg_id=4473903
guys, it's time to listen to community. If we are many to post here, it's to help and to prevent disasters, not to flame. The first alert dealed with GIJOE. The second with the need of further testing before releasing (http://sourceforge.net/forum/message.php?msg_id=4484560). The third with the need to secure code urgently.
Moreover, I really hope that next release will have a due public RC stage, instead of close testing.
marco
Hi guys,
I was not aware of all this before yesterday when a user reported this in our skype room. I investigated the problem and was on the impression that the resosurce.db.php we had in our extra folder was addressing this issue. I posted this on Gijoe's web site. The thread is there :
http://xoops.peak.ne.jp/md/d3forum/index.php?topic_id=2617#post_id9651
So as of now, I'm still not sure if the file we have in the extra folder does solve this problem or not. Anyone can confirm ?
Also, Gijoe explained the problem here http://xoops.peak.ne.jp/md/d3forum/index.php?topic_id=2617#post_id9651, which, of course, did not read yesterday.
So my opinion is that the changes introduced by Skalpa in the template system of 2.0.14 are good :
-- Try to read /themes/(your_theme)/modules/(dirname)/(templates) first. (1)
-- Try to read /modules/(dirname)/templates/(templates) second. (2)
This causes problem for module that do not have their templates in modules/(dirname)/templates/. So Gijoe is proposing as an alternative, to add another ELSE after those 2 verification :
-- Else read DB template ... (3)
Which makes sense to me. Everyone will be happy.
So my sugestion :
1- Wwe make an offical statement that in order to support some module, you can use this new resource.db.php, to inform people
2- If we need to publish a 2.0.17 for an important bug, then we include this new resource.db.php
Here are my 5 cents. What do you guys think ?
Cheers !
[quote]
1- We make an offical statement that in order to support some module, you can use this new resource.db.php, to inform people
2- If we need to publish a 2.0.17 for an important bug, then we include this new resource.db.php
[/quote]
I think you meant 2.0.18? Anyway, yes, it makes sense to me as well. I encourage the official statement to be as clear and easily found as possible, including a note on the Download XOOPS page of xoops.org. This was a problem with a bug in 2.0.15 that could only be fixed by downloading one extra file and for a long time, there was zero indication when you downloaded XOOPS from xoops.org that you also needed this other file.
Thank you for taking the time to investigate and clarify this Marc!
--Julian