Hi there guys, I've a question about the usage of user post/edit articles on NEWS 1.4.

I see that when a normal user (not webmaster) submits an article, only the Scoop textarea shows up, and all the other advanced controls are hidden from view. Thats nice but, if I let the users to edit their own post, on the edit screen all the other controls become visible, some of them (like the publish in home or expiration) not really suitable for a normal user.

Dunno if this is by design or a bug, but anyway this is not my real problem. The fact is that I want to let the users to write both the SCOOP text and the EXTENDED text. The only way seems to let them edit the post, but this way the users gets way too many controls that I don't want them to touch.

There is a way to proceed to baypass this?

About this, I think that an auto truncate system (scoop text truncated to N lines and the rest become extended text) can be a nice addition to the module.

if you give the regular users full access, and then find the template for the news submission form, you can surround the options that you do not wish the users to have with the following information;

<{if $xoops_isadmin}>
[option that only an admin should have]
<{/if}>

Make a back up of the file first so that if you make a mistake or run into problems, you can put it back to the way it was....

I'm glad there's an answer to that problem, it's been annoying the hell out of me for a looooooooonnnnggggggg time. Is this a bug, or is it the way the News module is supposed to work?

think thats the way its supposed to work.
my thoughts on that are:
admins usually 'approve' news articles submitted to the site by regular users, and they would be the ones to activate the extended text.
Due to the 'methodology' used for programming that scenario, the edit functions and all else fit into the same category.
Nowadays it seems that MANY of the people using XOOPS are creating 'seudo admins' that are contributing to the sites in many ways and administering select functions within it (the ideal web community), however, these people are not always known well enough to be trusted with complete control of the module or the site.

Hopefully future development of the core and the new module structure that goes with it will allow for selective admin privelidges on all of the forms used in the module (we're seeing that with the new customizable user registration form).

So it seems only logical...to me any way...that the next progression of that will be to be able to assign access to specific areas of the modules admin functions. (Imagine each module having group perms and settings like the XOOPS core does, so each new module you install can be customized almost as much to the full extent of the XOOPS core, without affecting the core)

Anyway, the best part about it is that the code for the XOOPS cms is pretty straight forward and workarounds can be done without too much aggravation!

Jeez, I hope you're right. I'm running sites with a lot of reader-submitted articles, and poring through each one to find the phrase that pays to use as an intro to each article is a pain in the...

Thanks Adrock. I was worried bout touching the PHP code to solve this, but your template-side solution is fantastic. Thanks again.

@gestroud: thats exactly the situation I want to avoid. Still I bet that the best solution is to show both text areas to the user or, ideal but perhaps not possible by design, autotruncate the scoop text in the same way Drupal's news module do. As Adrock says, lets see what happens when they start to use the new 2.2 functions.

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?

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;