Compared to this report:
https://xoops.org/modules/newbb/viewtopic.php?topic_id=41866&forum=39&post_id=183442

The notification system is active by default now, and the default method reverts to "email" if you don't install the private message module (good thing). But still I can't see the usual notification area on the bottom of the page until I assing it as a block. Is that the intended method? Because this way I get some problems against some module blocks.
Graphical glitch for IE users is still there.

Please, remember this thread also :)
https://xoops.org/modules/newbb/viewtopic.php?topic_id=41866&forum=39&post_id=183442

@blindman: take a look to the issues I reported here to see if they can be useful to solve your problem.

Hi there. I get some time to test a bit the 2.2.3 RC2 snapshot and run into a couple of problems. I'm not sure if they are bugs (thats why I prefer NOT to report them) and also, I can't reply on the betatester forum, so, here there is this thread.

My system:
Windows NT 5.0 build 2195
Badblue 2.64 Personal Edition
PHP Version 4.2.1
MySQL 3.23.39

After a clean installation all seems to work smooth, previous problems with PHP 4.2 seems solved, but:

1- The default notifications options at the bottom of each page are gone, I must activate it as a block from the admin (is that right?).

2- [Notifications] are disabled by default for every new user, and can't be overrided.

3- [Profile] Users can't activate notifications because the "Notification Method" field is not editable or visible by default (you must set it visible mannually).

4- [Profile] On Notification Method field, "private message" is showed as an option even when the Private Messaging module is not installed.

5- [Blocks Administration] There are 3 "All module pages" options in the "visible" box. I know that they are different branches, but is confusing anyway.

6- There is still a graphical glitch on the default template if you use IE 5.5 or 6.0:

[theme_moduleadmin.html]

Quote:
Well, thats exactly my point. Currently every module has its own template and in fact, they act as a small individual script attached to the main core.
Thats good because every module can be as powerful as their creator want, BUT if the default template don't look good with your customized css, you might start to find some problems. Not only you must change every module template, but sometimes this changes must be addressed inside the php code (for example, to get rid of "create pdf" option, etc).
That's a little away to the concept of "create a theme for xoops" but perhaps some people feels overhelmed by that.

@Herko: again, glad to heard that. Seems that you folks are moving in the way I feel is the correct one. Sorry if I sound a bit self-confident, but its because I feel that your work is beign despised by thouse small facts.

Mmm I wish I could help, but currently I have too many projects running on. The idea is good anyway, I think that the critic about the themes being "difficult to create" can be aimed to the fact that every module has their own template, and it´s tedious to modify every one to match the whole site.
Back to the topic idea, I insist that the first theme that must be updated must be this one. XOOPS needs a new front to match Mambo's and Drupal's more agressive sites.

Hi, I'm in process of select a forum system to my site.

Currently I'm using Newbbex (wich I preffer over cbb 2.2 because is small in size and simple to use).
There is any way to make it work with the editor framework of XOOPS 2.2? (to integrate the Koivi)

Personally I don't see waht's the matter about it, on the user side, that is. I remember a post asking about to keep 2.0 series up to date while 2.2 is being developed, and the Cube team is doing just that. So, is better this way really.

Besides that, I really think that what XOOPS Team needs now is time to fix things up, not only on their code, but in the way the product shows up. On the site organization, on the way modules are developed and (most important) the way they actually reach the user. A new image to the public can be refreshing right now.

Another posible bug: when the user post an article, the NOHTML option is always off (because he/she don't have the checkbox visible). That means bad news if you're using a HTML editor like Koivi.

HTML editor users, to quick fix this:

- File: submit.php
-- Find line 278: --
$nohtml_db = 1;
-- REPLACE --
$nohtml_db = 0;

Mmmm seems that there is no template for the submit form. To add a Extended Text textarea you must modify the storyform.inc.php and the submit.php file, as follows:

-- FILE storyform.inc.php
-- Line 92:
if ($approveprivilege) {
-- DELETE
-- Line 100:
Find the matching }
-- DELETE

-- FILE submit.php
-- Line 217:
$story->setBodytext($_POST['bodytext']);
-- MOVE OUT OF:
if {}
-- Line 254:
$bodytext = $story->bodytext("InForm");
-- MOVE OUT OF:
if {}
-- Line 264:
if ($approveprivilege) {
-- DELETE
-- Line 267:
Find the matching }
-- DELETE
-- Line 343:
if (isset($_POST['bodytext'])) {
$story->setBodytext($_POST['bodytext']);
} else {
$story->setBodytext(' ');
}
-- MOVE OUT OF:
if {}


Also, if you want (like me) to make the "scoop" area smaller than "extended text", you can modify storyform.inc.php:

-- Line 87:
$editor=news_getWysiwygForm(_NW_THESCOOP, 'hometext', $hometext, 15, 60, 'hometext_hidden');
-- REPLACE WITH
$editor_configs['name'] ='hometext';
$editor_configs['value'] = $hometext;
$editor_configs['rows'] = 15;
$editor_configs['cols'] = 60;
$editor_configs['width'] = '100%';
$editor_configs['height'] = '200px';

$editor=new XoopsFormEditor(_NW_THESCOOP, getmoduleoption('form_options'), $editor_configs, $nohtml=false, $onfailure="dhtmltextarea");

NOTE TO NEWS 1.4 DEVS:
I was forced to use 2.2 framework to acomplish this, because I was unable to alter the textarea height using your own function. Seems that even when there are values for rows and cols, they become static later in the function, (line 169 of functions.php), WHY?