Pligg Support

Reference post

I fixed the issue with banned or flagged members being still able to share and do activities as normal. In addition, I am working on fixing the issue of the Edit button being displayed, even for the Group Creator and Group Admin, which is incorrect and leads to no effective actions.

The questions is:

If there is another Admin and Moderators of the Group:

1- None of the privileges are displayed to them
2- The second Admin can ban, flag, change role of the creator of the Group BUT CANNOT deactivate the Creator and Admin of the Group. However, a Moderator can do all!!!

Are Admins and Moderators supposed to have banning, flagging, editing members roles and status privileges the same as the Creator? Are they supposed to apply those privileges even on the Creator of the Group?

Please provide the answers so that I continue fixing the groups features accordingly!
I am building up a site at and managed to add a few products in there initially, but have made quite a few changes including to latest version but I can no longer post. Would having $ signs in my category names create an issue ? I don't get an error messages - just nothing posts.
Hi all. i need to know about you'r experience.. does it more better if using only facebook dan twitter module for user registration?..

I thing this will more strong to avoid the spamming.. what do you'r thing?..

If the Group creator "Banned" a Group member, it has no effect and the banned member can still share stories to that Group. The banned member's profile shows he's still joined in that group.

If the Group creator edit the member to become Admin or Moderator, the edited member still doesn't have permissions as an Admin or moderator.

The Group creator can even banned himself and still he's the Admin of that group. IMO, the original Group creator should not be able to banned himself or set it's role to just Normal & Moderator.

There was a bug with already voted and already buried buttons.
When a person voted for or buried something the buttons changed classes into btn-success or btn-danger. After refreshing page the buttons stayed as they were supposed to. When a person changed his/her mind and wanted to 'un-click' the vote, btn-succes or btn-danger classes were removed and the link for already voted or already buried lost a btn class and was left without any indicator that it's a button.
Now it's fixed and you can see it here:

I've created a fork request for it
I committed it on my forked pligg too.
table_tags and table_tag_cache are updated in two cases:

1. Upon submitting a new story.
2. Every time a story is edited.

In the first case, in \submit.php, LINE 428, we find a call to a function in the \libs\tags.php file: tags_insert_string($linkres->id, $dblang, $linkres->tags);

However, at this stage the status of the story being submitted is still ‘discard’, while in the Function tags_insert_string, it specifically selects from table_links only the links that meet the status of published or new, therefore the new tags entered for story being submitted won’t be included and won’t appear in the tag cloud until the next submit (and again the newest tags won’t be included) or when the admin deletes the discarded stories from the admin section and automatically rebuilds the table_tag_cache.

After following the logic of the process, the best place to call the Function tags_insert_string is after we make sure that the story’s status is set to publish:

1. In \submit.php, LINE 428, comment or remove this code:

tags_insert_string($linkres->id, $dblang, $linkres->tags);

2. On LINE 517, after
function do_submit3() {

change this: global $db;

To this: global $db, $dblang;

Because we need the database language for the table_tags entries

3. On LINE 549, right after:


Add this (the code we commented or removed in step 1)

Step One

If we set the value of “Negative votes to remove submission” in Admin Panel -> Settings -> Voting to any number other than zero, all submitted stories after this change will be discarded. The code is inaccurately processing the “buries_to_spam” variable which reflects the value set above.

To fix this bug see the link:

Step Two

In Admin Panel -> Settings -> Voting -> Negative votes to remove submission is set to 0 by default. However, in the current code, this defined variable that is assigned to buries_to_spam does not achieve its goal to set the story status to 'discard' when it reaches the number we set in here. As a matter of fact, even with the default value of 0, the story will be sent to discard. The fact is that the function evaluate_formulas () in \libs\link.php is what decides the status of the story when the formula set in the table_formulas is evaluated.

See the complete trace and fix:
In the Pligg 1.2 script there was a great function that allowed to give random votes to submitted news. Is there something similar for Pligg 2.x?
Hi, I have found following bug. On second step of submitting story when you want to cancel submission you can't unless you select category. After that everything is fine
I send comments with words included on the spam list, the adversating is sent to the user but the comment doesn't go to moderation.