xoops-trackers Mailing List for XOOPS Web Application System

Bugs item #2937469, was opened at 2010-01-22 22:15
Message generated for change (Comment added) made by ianez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2937469&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dave f (ianez)
Assigned to: Nobody/Anonymous (nobody)
Summary: html entities in default block names/description

Initial Comment:
The names and descriptions for standard blocks (like User Menu or else) are passe via the defines setted in system/language/language_name/modinfo.php..
Actually on fresh 2.4.3 installation the names and description don't seems to understand html entities like 'ù'.. which is returned as written and not 'ù'.
Is there a problem in santizing names/description?

Thanx
Ian

----------------------------------------------------------------------

>Comment By: dave f (ianez)
Date: 2010-01-26 12:16

Message:
a solution to the problem could be to write _MI_SYSTEM_BNAME2 in the
database instead of directly writing the text.. that way I think sanitizing
could work

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2937469&group_id=41586

Bugs item #2938689, was opened at 2010-01-24 17:22
Message generated for change (Settings changed) made by ianez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2938689&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dave f (ianez)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Warnings in admin panel also for renamed folders

Initial Comment:
Renamend xoops_data and xoops_lib (not out from the xoops root), with working .htacces file should not generate, in my opinion, a security warning, 
or at least should generate a simple notice (coloured orange or else) saying that the best solution could be moving the folder outside the root.
This preventing many user getting worried about those warnings..
As you may know a few hosting services allow to have folders out of the html root in basic hosting profiles, and users don't like to buy a domain and then have to put their site in www.mydomain.com/site.

Ian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2938689&group_id=41586

Bugs item #2938689, was opened at 2010-01-24 17:22
Message generated for change (Tracker Item Submitted) made by ianez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2938689&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dave f (ianez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Warnings in admin panel also for renamend folders

Initial Comment:
Renamend xoops_data and xoops_lib (not out from the xoops root), with working .htacces file should not generate, in my opinion, a security warning, 
or at least should generate a simple notice (coloured orange or else) saying that the best solution could be moving the folder outside the root.
This preventing many user getting worried about those warnings..
As you may know a few hosting services allow to have folders out of the html root in basic hosting profiles, and users don't like to buy a domain and then have to put their site in www.mydomain.com/site.

Ian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2938689&group_id=41586

Feature Requests item #2938677, was opened at 2010-01-24 17:04
Message generated for change (Settings changed) made by ianez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2938677&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Administration
Group: XOOPS 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dave f (ianez)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Automatic caches clean

Initial Comment:
Not all the users are experienced enough to delete cache files, above all now that there are more tha one cache folder..
An option could be to have direct an optional cleaning of the caches during system module update process
This could be a little but very useful improvement for basic users

Ian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2938677&group_id=41586

Feature Requests item #2938677, was opened at 2010-01-24 17:04
Message generated for change (Tracker Item Submitted) made by ianez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2938677&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Administration
Group: XOOPS 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dave f (ianez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gui for cleaning caches

Initial Comment:
Not all the users are experienced enough to delete cache files, above all now that there are more tha one cache folder..
An option could be to have direct an optional cleaning of the caches during system module update process
This could be a little but very useful improvement for basic users

Ian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2938677&group_id=41586

Bugs item #2938675, was opened at 2010-01-24 17:00
Message generated for change (Tracker Item Submitted) made by ianez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2938675&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dave f (ianez)
Assigned to: Nobody/Anonymous (nobody)
Summary: some templates 'lost' after system module update

Initial Comment:
On xoops 2.4.x and even 2.4.4 after updating the system module, the redirect template and the closed site template seem to lose connection with the file and you can se only plain-text version (as an html page without css).
Manually cleaning the smarty_compile seems to solve the problem. All permissions for xoops_data are ok.
The bug showing on both linux and windows server, clean or upgraded installation of xoops

Ian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2938675&group_id=41586

Bugs item #2937966, was opened at 2010-01-23 15:43
Message generated for change (Tracker Item Submitted) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2937966&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reusing loop variable in preferences

Initial Comment:
In modules/system/admin/preferences/main.php, there is some kind of nested loop in the save part

for ($i = 0; $i < $count; $i++) {
...
   for ($i = 0; $i < $dcount; $i++) {
...
   foreach (array_keys($imagefiles) as $i) {
and reuse of the variable $i .
Is that correct?

See also 
http://www.xoops.org/modules/newbb/viewtopic.php?topic_id=70060&forum=72&post_id=319654#forumpost319654



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2937966&group_id=41586

Bugs item #2937906, was opened at 2010-01-23 12:58
Message generated for change (Tracker Item Submitted) made by arabxoops
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2937906&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: arabxoops (arabxoops)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unused lang defines

Initial Comment:
System module using lang defines from language folder in the root. and some lang defines not used at all, example:

define("_AM_LEFT","Left");
define("_AM_RIGHT","Right");
define("_AM_CENTER","Center");

in file : modules/system/language/english/admin/blocksadmin.php




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2937906&group_id=41586

Bugs item #2937469, was opened at 2010-01-22 22:15
Message generated for change (Tracker Item Submitted) made by ianez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2937469&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dave f (ianez)
Assigned to: Nobody/Anonymous (nobody)
Summary: html entities in default block names/description

Initial Comment:
The names and descriptions for standard blocks (like User Menu or else) are passe via the defines setted in system/language/language_name/modinfo.php..
Actually on fresh 2.4.3 installation the names and description don't seems to understand html entities like 'ù'.. which is returned as written and not 'ù'.
Is there a problem in santizing names/description?

Thanx
Ian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2937469&group_id=41586

Bugs item #2928289, was opened at 2010-01-08 14:08
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
>Status: Closed
Resolution: Fixed
Priority: 7
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: trabis (trabis)
Summary: XOOPS object behaviour modified

Initial Comment:
When the objecthandler is asked to get an object with ID null or 0, a new emtpty object is created.
For 2.4.3, the object is only created when requested with ID null.
Some modules rely on this behaviour eg Article.
See this:
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322378#forumpost322378
Solution 
Restore
if (!isset($id)) {
to
if (empty($id)) {   
in line 1070 in /kernel/object.php in function get.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-01-18 02:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 7 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: trabis (trabis)
Date: 2010-01-10 14:05

Message:
Fixed on 2.4.4 branch by using  2.3.x code.

----------------------------------------------------------------------

Comment By: Gerard Vanderveken (ghia)
Date: 2010-01-10 11:18

Message:
I don't think the isset is necessary, this is already being taken care by
the empty.
It will not doing something extra to the original line 
if (empty($id)) { 
so the extra test is useless.

----------------------------------------------------------------------

Comment By: Simon Roberts (wishcraft)
Date: 2010-01-10 07:24

Message:
This has been address line 1070 in next revision commitment will read:

if (!isset($id)||empty($id)) {

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Feature Requests item #1537501, was opened at 2006-08-09 18:28
Message generated for change (Comment added) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1537501&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wodening (wodening)
Assigned to: Nobody/Anonymous (nobody)
Summary: Suspend and Ban Users

Initial Comment:
The ability to suspend users for a specified amount of
time, and ban users on an as needed bases, and issue
warnings.

----------------------------------------------------------------------

>Comment By: Gerard Vanderveken (ghia)
Date: 2010-01-12 11:12

Message:
With some automated registering, some sites can have up to 300 banned
users.
The current practice is to put them in a banned user group, where they
have no rights at all when logged in.
However their names appear in all user lists and thus hindering regular
operations.

So, there should be an additional status for the user, in the way of
activated for being banned.
Administrators can simply set a yes-no in the edit of a users profile.
Result is that:
The user looses all the regular permissions (permission handler checks
this flag and returns empty permission)
User lists exclude these members.
Other operations as eg notifications are skipped.
 

----------------------------------------------------------------------

Comment By: TKBOW (gmax21)
Date: 2006-08-27 07:19

Message:
Logged In: YES 
user_id=695829

an optional field with a mailer option would also be good,
to inform the member, via E-mail that they have been banned
and why.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1537501&group_id=41586

Bugs item #2929739, was opened at 2010-01-11 12:39
Message generated for change (Tracker Item Submitted) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2929739&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Block editor example is different from real result

Initial Comment:
When in editing a custom block with HTML type a BBcode is used as eg [img]http://www.xoops.org/images/subject/icon3.gif[/img], then this image is showed in the preview area of the DHTML preview button, but in the final block the raw text will be showed. This raw text is also correct showed  with the preview button and the popup window with the block. 
This different behaviour of the two previews confuses the users:
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322248#forumpost322248

Solution has to make sure that the editor preview shows the same as the final result, depending on the block type. If this is not possible, the function of editor preview should be suppressed by eg adding #bcontent_hidden_data {display: none;} to the CSS file  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2929739&group_id=41586

Bugs item #2928289, was opened at 2010-01-08 14:08
Message generated for change (Settings changed) made by trabis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
>Status: Pending
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: Gerard Vanderveken (ghia)
>Assigned to: trabis (trabis)
Summary: XOOPS object behaviour modified

Initial Comment:
When the objecthandler is asked to get an object with ID null or 0, a new emtpty object is created.
For 2.4.3, the object is only created when requested with ID null.
Some modules rely on this behaviour eg Article.
See this:
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322378#forumpost322378
Solution 
Restore
if (!isset($id)) {
to
if (empty($id)) {   
in line 1070 in /kernel/object.php in function get.

----------------------------------------------------------------------

>Comment By: trabis (trabis)
Date: 2010-01-10 14:05

Message:
Fixed on 2.4.4 branch by using  2.3.x code.

----------------------------------------------------------------------

Comment By: Gerard Vanderveken (ghia)
Date: 2010-01-10 11:18

Message:
I don't think the isset is necessary, this is already being taken care by
the empty.
It will not doing something extra to the original line 
if (empty($id)) { 
so the extra test is useless.

----------------------------------------------------------------------

Comment By: Simon Roberts (wishcraft)
Date: 2010-01-10 07:24

Message:
This has been address line 1070 in next revision commitment will read:

if (!isset($id)||empty($id)) {

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Bugs item #2929230, was opened at 2010-01-10 12:29
Message generated for change (Tracker Item Submitted) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2929230&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: DHTML AJAX can tackle server

Initial Comment:
When editing long News articles with the DHTML editor and using the preview button of the editor, can tackle the internetserver.
The site becomes disabled for a time.
This is partly a bad server security issue, but also bad practice in XOOPS.

The problem is the AJAX preview request and exposes in FireFox and Opera browsers. The IE uses another method with the MSXML libs.
The problem is that the AJAX request is sent as a long URL (GET) in function form_instantPreview of /include/formdhtmltextarea.js 
function form_instantPreview(xoopsUrl, area_id, imgurl, doHtml)
{
    var imgUrl = xoopsUrl + '/images/form';
    var data = escape(xoopsGetElementById(area_id).value);
    var url_request = xoopsUrl + "/include/formdhtmltextarea_preview.php?text=" + data;
    if (doHtml) {
        url_request += '&html=' + doHtml;
    }
    makeRequest(area_id, url_request, null);  // - Made ajax Hidden
}
It should be converted to use a POST request.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2929230&group_id=41586

Bugs item #2928289, was opened at 2010-01-08 15:08
Message generated for change (Comment added) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: XOOPS object behaviour modified

Initial Comment:
When the objecthandler is asked to get an object with ID null or 0, a new emtpty object is created.
For 2.4.3, the object is only created when requested with ID null.
Some modules rely on this behaviour eg Article.
See this:
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322378#forumpost322378
Solution 
Restore
if (!isset($id)) {
to
if (empty($id)) {   
in line 1070 in /kernel/object.php in function get.

----------------------------------------------------------------------

>Comment By: Gerard Vanderveken (ghia)
Date: 2010-01-10 12:18

Message:
I don't think the isset is necessary, this is already being taken care by
the empty.
It will not doing something extra to the original line 
if (empty($id)) { 
so the extra test is useless.

----------------------------------------------------------------------

Comment By: Simon Roberts (wishcraft)
Date: 2010-01-10 08:24

Message:
This has been address line 1070 in next revision commitment will read:

if (!isset($id)||empty($id)) {

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Bugs item #2928289, was opened at 2010-01-09 01:08
Message generated for change (Comment added) made by wishcraft
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: XOOPS object behaviour modified

Initial Comment:
When the objecthandler is asked to get an object with ID null or 0, a new emtpty object is created.
For 2.4.3, the object is only created when requested with ID null.
Some modules rely on this behaviour eg Article.
See this:
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322378#forumpost322378
Solution 
Restore
if (!isset($id)) {
to
if (empty($id)) {   
in line 1070 in /kernel/object.php in function get.

----------------------------------------------------------------------

Comment By: Simon Roberts (wishcraft)
Date: 2010-01-10 18:24

Message:
This has been address line 1070 in next revision commitment will read:

if (!isset($id)||empty($id)) {

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Feature Requests item #2928871, was opened at 2010-01-09 16:41
Message generated for change (Comment added) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928871&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Administration
Group: XOOPS 2.4
>Status: Deleted
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Having preferences for the textsanitizer config files

Initial Comment:
Many Items in the textsanitizer are configurable via php config files.
These should be moved to a new preference category eg Display options.
There can then be set if the Carica routine is to be used, and the width for limiting the images.
See this
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322435#forumpost322435
Other preferences in this category allow the setting of the captcha parameters etc.
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=319860#forumpost319860
This would allow personal settings and variations in the captcha images, what makes it also more difficult for SPAMmers to crack it.

In general all file configurations should move to the preference system.

----------------------------------------------------------------------

>Comment By: Gerard Vanderveken (ghia)
Date: 2010-01-09 16:47

Message:
Sorry, got double posted after SourceForge Server break.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928871&group_id=41586

Feature Requests item #2928872, was opened at 2010-01-09 16:42
Message generated for change (Tracker Item Submitted) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928872&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Administration
Group: XOOPS 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Extended debug preferences

Initial Comment:
The debug should get its own category of preferences, allowing better control of debug.
The current general system debug preference, will still be used, but only to switch it on or off.
In the new debug category, preferences are present for:
Smarty debugging: off (or on) 
PHP debugging:on (or off)
PHP debug display: inline (or popup)
Show to groups: webmasters (multiselect other groups in anonymous) 
Limit to IP: off (or on)
IP number (if previous is on, debug messages will only be showed to this IP number (or if possible, range eg 123.45.*) )

Next is a division by message type of the PHP debug:
Show message types: All PHP error classes can be selected on or off

Introducing also the E_USER_DEPRECATED type, which group all deprecated messages.
These messages have nothing to do with the good functioning of a XOOPS site and they are of no interest for the regular XOOPS user and are only ballast for the site, the user, the XOOPS forum and the XOOPS support team.
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322452#forumpost322452
Too many times users are needless alarmed by these deprecated messages and as their numbers are always increasing, they may hide or distract the real problems.
Only module developers should see them.
Making use of this constant may allow to turn these errors' display selectively on or off.
If the constant is not available as in PHP < 5.3.0, a check with ifdefined should define it.

Maybe the settings one by one for each type is too much asked, but at least some grouping should be possible as eg user standard, user extended, developer.

If later, other debug possibilities are added, then this preference category can accomodate the settings needed for that, eg:
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=320432#forumpost320432 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928872&group_id=41586

Feature Requests item #2928871, was opened at 2010-01-09 16:41
Message generated for change (Tracker Item Submitted) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928871&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Administration
Group: XOOPS 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Having preferences for the textsanitizer config files

Initial Comment:
Many Items in the textsanitizer are configurable via php config files.
These should be moved to a new preference category eg Display options.
There can then be set if the Carica routine is to be used, and the width for limiting the images.
See this
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322435#forumpost322435
Other preferences in this category allow the setting of the captcha parameters etc.
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=319860#forumpost319860
This would allow personal settings and variations in the captcha images, what makes it also more difficult for SPAMmers to crack it.

In general all file configurations should move to the preference system.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928871&group_id=41586

Feature Requests item #2928866, was opened at 2010-01-09 15:26
Message generated for change (Tracker Item Submitted) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928866&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Administration
Group: XOOPS 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Having preferences for the textsanitizer config files

Initial Comment:
Many Items in the textsanitizer are configurable via php config files.
These should be moved to a new preference category eg Display options.
There can then be set if the Carica routine is to be used, and the width for limiting the images.
See this
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322435#forumpost322435
Other preferences in this category allow the setting of the captcha parameters etc.
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=319860#forumpost319860
This would allow personal settings and variations in the captcha images, what makes it also more difficult for SPAMmers to crack it.

In general all file configurations should move to the preference system.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928866&group_id=41586

Bugs item #2928289, was opened at 2010-01-08 15:08
Message generated for change (Tracker Item Submitted) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: XOOPS object behaviour modified

Initial Comment:
When the objecthandler is asked to get an object with ID null or 0, a new emtpty object is created.
For 2.4.3, the object is only created when requested with ID null.
Some modules rely on this behaviour eg Article.
See this:
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=322378#forumpost322378
Solution 
Restore
if (!isset($id)) {
to
if (empty($id)) {   
in line 1070 in /kernel/object.php in function get.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2928289&group_id=41586

Feature Requests item #2928215, was opened at 2010-01-08 12:53
Message generated for change (Tracker Item Submitted) made by ghia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928215&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Administration
Group: XOOPS 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Overview registration steps

Initial Comment:
The profile module allows to define registration steps and user fields.
If I'm not mistaken, up to now there is no listing where one can see  which fields belong to which registration step.
(In edit field the step can be edited, but this is tedious as one must open each field)

EG The field listing should be extended with a column to list the step to which the field belongs.
/modules/profile/admin/field.php


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2928215&group_id=41586

Bugs item #2917631, was opened at 2009-12-19 14:07
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2917631&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.4.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Gerard Vanderveken (ghia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Double frame around BBcode quotes in zetagenesis

Initial Comment:
The BBcode quote tags eg [quote]This is a quote[/quote] 
are translated to 
Quote:<div class="xoopsQuote"><blockquote>This is a quote</blockquote></div>
which is correct, but in the CSS file of zetagenesis both the xoopsQuote class and the blockquote tag are style with a frame (outline), which makes that the text has a double border. Obvious one too many!
This is no problem with the default theme.
Solution could be to have
div.xoopsQuote blockquote {border:none;}
in content.css    

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-01-08 02:26

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 7 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: mamba (beckmi)
Date: 2009-12-31 16:39

Message:
Fixed in SVN

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2917631&group_id=41586

Bugs item #2923867, was opened at 2009-12-30 23:20
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2923867&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules - Profile
Group: XOOPS 2.4.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: mamba (beckmi)
Assigned to: trabis (trabis)
Summary: Profile Module - Website Row is displayed even value is empt

Initial Comment:
the website row in template is displayed even when the url value is empty

should be hidden if the value is empty ..just like other field....

See: 
http://www.xoops.org/modules/newbb/viewtopic.php?post_id=321887#forumpost321887

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-01-07 02:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 7 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: mamba (beckmi)
Date: 2009-12-30 23:21

Message:
Fixed in SVN and waiting for review

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=2923867&group_id=41586

Feature Requests item #2926969, was opened at 2010-01-06 15:45
Message generated for change (Tracker Item Submitted) made by sabahan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2926969&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj (sabahan)
Assigned to: Nobody/Anonymous (nobody)
Summary: A collection of Request

Initial Comment:
many wishlist are listed here...
http://www.xoops.org/modules/mediawiki/index.php/Wishlist_for_Next_XOOPS

some of it has been granted ..

some of it still pending

please consider them

TQ

xoops lover (sabahan)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=2926969&group_id=41586