11
MaxIT
Re: Pre-moderating forums: an idea
  • 2002/7/11 14:52

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


Quote:
Where can I download it ?

Wait some, I still need to make it decently working.
Quote:
Does your hack permits to choose which level of user would pass through the moderation ?

I didn't though about this, it's very interesting feature, quite simple to add. I'll put on my list.



12
MaxIT
Re: Pre-moderating forums: an idea
  • 2002/7/11 0:36

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


Quote:
Why not release it as a separate module instead of a hack so both modules can be used together?

That is a good idea. I should simply rename module and referring to same tables. At now it still need hacking db and /include/functions.php, but last could be solved by duplicating showThread function instead than hacking it.

BTW, I have some doubts on managing informations shared with other modules or blocks: recent discussions, user posts count and other stuff should all be re-built or hacked. I need some tests.



13
MaxIT
Re: Pre-moderating forums: an idea
  • 2002/7/10 18:24

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


(pre-)Hack is finished, it looks like working fine.

You can take a look at my RC3 Test Site.

Just login as testuser/testuser and post anything. Logout, then look at your thread, will be empty. Login again as testmoderator/testmoderator, look in the threads, and you will se a button: if you press the 'red' one, it will hide the post; if you do the 'green' one, it will unhide it.

Known bugs:

- incongruency in user/thread/forum posts count (it involves too many code lines)
- if thread has not at least 1 post unhided, it should not appear on forum threads list (this is a mess, except by adding further field and logic for threads table)
- if post is sent from a moderator, it should be implicitally approved (easy one)
- post should be see from owner, too (not sure)
- forum module admin should have same rights as moderator (just a keyword)



14
MaxIT
Re: Pre-moderating forums: an idea
  • 2002/7/10 17:06

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


Quote:
I think you have a very nice idea...of course we accept any contribution by users any time..

I almost finished the hack: I just need to work on viewpost.php for filtering posts according to user permission, and add a checkbox "moderated" on forum administration.
It will be a beta because I think I'll get some posts-related problem like user-posts count and showing empty thread when all posts are hided (a better version should add a 'hide' flag to thread headers)
I'll release it soon.



15
MaxIT
Re: Pre-moderating forums: an idea
  • 2002/7/9 10:48

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


*bump*

(only 11 visits at now and could interests larger public)



16
MaxIT
Re: Account re-activation required on Profile email changes
  • 2002/7/8 14:17

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


Sorry, there is a bug in this hack:
you need to add this before line 123 to make it work properly:

$email = $xoopsUser->email("E");

Otherwise, $email value previously taken from text box will be empty ad an error will occour while you try saving user profile.



17
MaxIT
Pre-moderating forums: an idea
  • 2002/7/8 12:47

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


To let XOOPS forum moderators doing their job before the publish of what they should moderate, I'm thinking about an hack that should be simple.
The idea is following:
- add a db field in table PREFIX__bb_posts_text called post_approved.
- ad a db field in table PREFIX_bb_forums called forum_moderated
- when a user post a message, default value of post_approved will be = !forum_moderated
- for normal user, when forum engine will display messages, it will display only those ones in which post_approved = 1
- for moderators, forum engine will display all messages with an additional approve button (which will show the state of post_approved value, too). Clicking on it will switch post_approved field value.

I'm going do it on myself but I'm interested on knowing devs & community opinion about integrating this in official release.

Other than in France, in Italy too there is a problem of 'responsability' of site contents, including forums, and this is a important feature, IMHO.



18
MaxIT
Re: Account re-activation required on Profile email changes
  • 2002/7/5 15:18

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


Quote:
Currently, once a user had created an account, he could change his/her email address to anything without any verifications.

In the waiting for this useful fix, I've skipped this problem by removing the option to change the email by XOOPS users (RC2-only hack)

Just look at the edituser.php file at line 43:

<table cellpadding='8' border='0'><tr><td><form name='userinfo' action='edituser.php' method='post'><b>". _US_REALNAME ."</b> ". _US_OPTIONAL ."<br /><input class='textbox' type='text' name='name' value='". $xoopsUser->name("E")."' size='30' maxlength='60' /><br /><b>". _US_EMAIL ."</b> ". _US_REQUIRED ."<br />". _US_THISWILLBEPUBLIC ."<br /><input class='textbox' type='text' name='email' value='". $xoopsUser->email("E") ."' size='30' maxlength='60' /><br />". _US_OPTION ." <input type='checkbox' name='user_viewemail' value='1'";

and change it in this way:

<table cellpadding='8' border='0'><tr><td><form name='userinfo' action='edituser.php' method='post'><b>". _US_REALNAME ."</b> ". _US_OPTIONAL ."<br /><input class='textbox' type='text' name='name' value='". $xoopsUser->name("E")."' size='30' maxlength='60' /><br /><b>". _US_EMAIL ."</b> ". _US_REQUIRED ."<br />". _US_THISWILLBEPUBLIC ."<br />". $xoopsUser->email("E") ."<br />". _US_OPTION ." <input type='checkbox' name='user_viewemail' value='1'";

Rc3 is some different and I'm still working on it (but should be easier)

Why should use a temporary solution? well, as soon I've published on xoops.it about this issue, just 2 minutes after lots of trolls was subscribing with fantasious email addresses



19
MaxIT
Re: HTML problem in XOOPS and Other CMS?
  • 2002/7/5 14:14

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


Quote:
The reason XOOPS lowers the message you paste is that TextSanitizer has convert all line breaks (PC style \r\n, Unix style \n and Mac style \r) to <br> automatically

A suggestion: add an additional XOOPS code (like i.e. [ HTMLONLY ]) to core system. Then, all text inside the HTMLONLY tags will be text-sanitized in a different way, avoiding to switch newlines to BR automatically.

In this way, you can still use easily your short HTML tags inside a text, but if you want to insert large HTML codes you can put them between this new tag, so they will be showed exactly as they are without any exceeding BR .



20
MaxIT
Re: HTML problem in XOOPS and Other CMS?
  • 2002/7/5 13:11

  • MaxIT

  • Just popping in

  • Posts: 65

  • Since: 2002/11/8


Quote:
If you are using HTML in a post is because you want to have a defined layout of you information, and you are expecting it to be where you are putting it

I think it is a different point of view regarding the Section's scope: allowing the use of HTML tags does not mean it needs HTML contents. Instead, Sections module would allow an unexperienced user to write a simple text document, so it needs to make all newlines as BRs. A quick & dirty hack should be probably a check to where is located your newline, and in case it's in the middle of HTML-only text part, then should skip the BR sanitizer.




TopTop
« 1 (2) 3 »



Login

Who's Online

160 user(s) are online (106 user(s) are browsing Support Forums)


Members: 0


Guests: 160


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits