We are experiencing missing e-mail notification to some users on some Wiki Comments that were added. In studying the problem,
I came across this page >> I noted the statement >

Once you miss the email for a particular page change or don't visit the page (or ignore the email), you will not receive any more emails for that page. You can still dutifully monitor that page by its watchlist edit-summaries, but its particular email notification flag will remain unset until you visit it. This facilitates monitoring a large watchlist while preventing potentially useless emails to you.

Does Wacko Wiki follow the same concept? This would explain what we are seeing. If Wacko does the same, is there a way to turn off the elimination of notifications if an earlier notification was not responded to? Will simply visiting the page reinstate notification e-mails for that page?

1. Terms

  1. watch
    1. means the page is tracked for the user in the watch table
    2. to watch a page
      1. you can set a page manually on your watch list
      2. auto subscription adding every page to the watch list
        1. you've created (owner),
        2. edited (user)
        3. commented (user)
    3. the watch list is used
      1. by related action to indicate you changes since your last visit / [mark as read]
      2. the notify function to send you email notifications
  2. notify
    1. includes that you watch a page (already) AND that you will receive an email with a
      1. change set
      2. comment
    2. the frequency you receive email notification depends on your settings / preferences
      1. only the first change / comment until you revisit the page again
      2. every change set / comment
      3. mixed
      4. a digest per given period [not yet implemented]

when (Notification Types)

  1. new page
  2. changed page
  3. comment
  4. new user
  5. new owner
  6. password reset
  7. personal message
  8. pending changes / edit review
  9. new attachment

interval / threshold

  • instantly
  • pending / notification flag
    • Only one notification is sent on the first page change. Further mails are suppressed until you re-visit the changed page or until you reset all notification flags.
    • E-Mail: There will be no other notifications in case of further changes unless you visit this page.

You could also reset the notification flags for all your watched pages on your watchlist.

  • minor changes
  • mute
  • digest / bulk

who (roles)

  1. editor
  2. watcher
  3. new owner
  4. new user
  5. moderator
  6. admin

2. Functions


  1. send_mail($_user['email'], $subject, $body);
  2. notify_watcher($page_id, $comment_on_id, $tag, $title, $page_body = '', $user_id, $user_name, $is_revision);
  3. notify_moderator($page_id, $tag, $title, $user_name)

3. Actions

related actions

  1. watchers
  2. mychangeswatches
  3. mywatches
  4. userpages
  5. registration
  6. changepassword
  7. users

filter out actions

  1. diff (ACTION4DIFF)
  2. comment
  3. feed

Note: toc, anchor, include (comment, feed)

4. Settings


  1. enable_email == true
  2. enable_email_notification == true ->Turn email notifications on or off
  3. autosubscribe
  4. notify_minor_edit == true [true|false] -> Set to true to allow email notification for edits flagged as 'minor'.
  5. notify_page == 0** [0|1|2|3]
  6. notify_comment == 0** [0|1|2|3]
  7. General Notification Settings

user settings

  1. $user['enabled']
  2. $user['email_confirm']
  3. $user['send_watchmail']
  4. $user['allow_intercom']
  5. $user['allow_massemail']
  6. $user['notify_minor_edit'] -> Set to true to allow email notification for edits flagged as 'minor'.
  7. $user['notify_page']
  8. $user['notify_comment']

global / user threshold settings (radio / option)

  1. _comment (always, pending, digest, mute) default: always
  2. _page (always, pending, digest, mute) default: pending / first

# setting config user default

settings GUI access

  • user account
  • admin panel

message sets

  1. admin panel
  2. user
    1. minor edit - Email me also for minor edits of pages

I think we should give users more information right inside the interface what "Pending" option means.
Maybe like [?] with mouseover explanation text.

  1. Sending a email notification only for the first change until the user visits the page again.
  2. Sending a email notification only for the first comment until the user visits the page again.

5. Usability

usability issues

  1. frequency
  2. message sets
  3. settings
  4. actions

receive all messages combined in one digest

  1. daily at
  2. once per week on
  3. once per month, on the day number

6. Privacy

Add option to obey ACLs

  1. don't leak protected pages and files
    1. to Moderator
    2. in Email
  2. replace restricted content in notifications with generic info
    1. Link to Changes require to Login
  3. Digest
    1. new pages, new files, comments, changes, new users
      1. per page
      2. global

7. Notification Types

# when who what conditions message sets remarks
1 registration user action:registration
2 new page moderator
3 changed page watcher, owner diff(source) config['enable_email_notification'] == true
4 comment watcher, owner entire comment config['enable_email_notification'] == true TODO: filter out actions
5 new user admin
6 new owner owner
7 password reset user
8 personal message user
9 new attachment moderator, watcher
10 other


  1. email digest
  2. following
  3. group membership
  4. group request
  5. approve changes

7.1. email notification body

There will be no other notifications in case of further changes unless you visit this page.
You could also reset the notification flags for all your watched pages on your watchlist.

To change your watchlist settings, visit	

8. mixed encoding

function legacy_html_entity_decode($str, $quotes = ENT_QUOTES, $charset = 'UTF-8')
    return preg_replace_callback('/&#(\d+);/', function ($m) use ($quotes, $charset)
        if (0x80 <= $m[1] && $m[1] <= 0x9F)
            return iconv('cp1252', $charset, html_entity_decode($m[0], $quotes, 'cp1252'));

        return html_entity_decode($m[0], $quotes, $charset);
    }, $str);

9. Email header

9.1. Auto-Submitted Header

$mail->AddCustomHeader('Auto-Submitted: auto-generated');	// RFC3834
$mail->AddCustomHeader('X-Auto-Response-Suppress: All');	// Microsoft Exchange	

9.2. return-path and reply-to

When Wacko sends emails they go From: noreply_email.

$mail->Sender		= $this->engine->db->abuse_email;		// 'return-path' header	

The 'return-path' header declares the address where to send various bounce messages if any (undeliverable notifications, etc.)
As this is the administrative problem 'return-path' header can be admin_email (if we consider this should be just fixed) or abuse_email (if we consider this to be an incident like sending SPAM via WackoWiki mailing system). I guess in small WackoWiki installtions admin_email and abuse_email is the same address.

About 'reply-to' it's important when the user who got the message should answer to some address different from sender address.
I don't think this can be used in WackoWiki. "From:" is in most cases the proper reply-to. The webserver should be configured not to force "From:" to server user@host_name like they sometimes do e.g. "".

10. Errors

  1. encoding issues

11. Feeds

Additional to email notifications we also have feeds for

  2. changes
  3. revisions
  4. news

12. Troubleshooting Email Notifications

Not receiving notification emails
-> I’m not receiving email notifications.

  1. your wiki e-mail system must be working
  2. e-mail address must be marked as confirmed
  3. there are never notifications for your own changes
  4. only one notification is sent for the first page change of a page you are watching
  5. notification is automatically re-enabled when you visit the current version of the page
  6. you also can clear all notification flags at once (see watchlist)

I keep receiving email or text notifications I don’t want.

13. Userguide