Under Installation, it says:
- The database user must have been granted the "REFERENCES" right for the database.
Umm… OK, so how does one check whether this requirement is satisfied?
Extension talk:Echo
If you run SHOW GRANTS FOR 'wikiuser'@'localhost'; (or whatever your DB user and access mechanism is) it should give back a result – see upstream docs.
This should be added to the article. I assume 'wikiuser' should match $wgDBuser from LocalSettings.php?
This should be added to the article.
I don't think it should; it will depend on what database back-end you as a sysadmin have chosen to install.
I assume 'wikiuser' should match $wgDBuser from LocalSettings.php?
Sorry, yes.
Oh, wait… were you saying that 'wikiuser' should be used as a literal string in the SHOW command? (As you can tell, I have not had to do anything with databases since I installed my wiki, years ago.)
Is that an answer to my question about adding the information to the article or about the wikiuser matching $wgDBuser (or both, hence the semicolon)?
Sorry for the confusion! Have edited my answer to cover both.
Thank you for the clarification. I still say we should add something like what you have told me here to the instructions. If I had a question about this, then others will, too. And if your answer was good enough for me (debatable? [wink]), then something like it should be good enough for others. If the addition covers the one or two most likely configurations for someone like me, who set up their wiki in essentially complete ignorance (just followed Manual:Installing MediaWiki, the comments in LocalSettings.php, and Manual:LocalSettings.php), then that will be better than the current situation (IMO). As you can see, my understanding of these things is tenuous at best, so I'd rather you (or someone else) actually choose the wording.
…Or if it would be correct to say, "This is almost always the case.", we can just say that. Anything is better than leaving a reader with no idea what to do.
I just made a change that applies to my case (and likely that of many like me, who don't know what they're doing).
hi!
I configured the extension to send email notifications
it works :)
But in the body of the letter there is a link to the image and it is not displayed:
/load.php?modules=ext.echo.emailicons&image=user-rights&lang=en&format=rasterized
The picture can be seen if i replace 'rasterized' to 'svg'
I manually corrected the code in EchoIcon.php. this helped me, but is there probably some other reason?
// If the URL is null or false call the resource loader
// rasterizing module
if ( $url === false || $url === null ) {
$iconUrl = wfScript( 'load' ) . '?' . wfArrayToCgi( [
'modules' => 'ext.echo.emailicons',
'image' => $icon,
'lang' => $lang,
#'format' => 'rasterized'
'format' => 'svg'
] );
} else {
// For icons that are defined by URL
$iconUrl = $wgEchoNotificationIcons[ $icon ][ 'url' ];
}
| Product | Version |
|---|---|
| MediaWiki | 1.39.5 |
| PHP | 8.0.30 (fpm-fcgi) |
| MySQL | 8.0.36-0ubuntu0.20.04.1 |
| ICU | 66.1 |
| Lua | 5.1.5 |
| Pygments | 2.11.2 |
Hello, on the Notification Area if you go to "All notifications" you see the "Recent activity" with the sum line of the wiki in blue. On my installation i see here a "local" not the name of the wiki. On MediaWiki it shows me "MediaWiki". Where i have to set the name?
| Product | Version |
|---|---|
| MediaWiki | 1.32.5 |
| PHP | 7.2.17-0ubuntu0.18.04.1 (apache2handler) |
| MariaDB | 10.1.38-MariaDB-0ubuntu0.18.04.1 |
Hello,
my skin
| Skin | Version | License | Description | Authors |
|---|---|---|---|---|
| Metrolook | 7.0 alpha 2 (578ddcf) 19:13, October 11, 2018 | GPL-2.0-or-later | Metrolook is a Metro-inspired fork of the Vector skin | immewnity, Paladox, Craig Davison and lagleki |
does not show the tray icon next to the bell icon in the top-bar of my wiki, so I managed to show all the notifications in one place (the bell).
Despite every attempt, I haven't been able to redirect notifications to "alerts" (instead of "messages").
I tried (as suggested below by @Roan Kattouw (WMF)) with:
$wgExtensionFunctions[] = function () {
global $wgEchoNotifications;
// To change individual notification types:
$wgEchoNotifications['welcome']['section'] = 'alert';
// To change all notification types at once:
foreach ( $wgEchoNotificationTypes as &$data ) {
$data['section'] = 'alert';
}
};
in LocalSettings.php, and also to modify the file .../extensions/Echo/extension.json (as explained in Echo Extension Configuration section) like this:
"thank-you-edit": {
"user-locators": [
"EchoUserLocator::locateEventAgent"
],
"category": "system",
"notify-type-availability": {
"email": false
},
"group": "positive",
"presentation-model": "EchoEditThresholdPresentationModel",
"section": "alert"
},
but without success.
What should I do?
Hi, I don't know if you're still looking for an answer, but I managed to display all notifications under the bell icon (so I can hide the tray icon, I don't see the point of having two icons), with this code :
$wgExtensionFunctions[] = function () {
global $wgEchoNotifications;
foreach ( $wgEchoNotifications as &$data ) {
$data['section'] = 'alert';
}
};
Thanks, your messages helped.
Thank you so much.
Exactly what I needed, thanks a lot. Any clarification on why it is implemented with two icons instead of one ?
There's "alerts" and "notifications". "alerts" are important and "notifications" are not. That way, important messages don't get spammed away by other messages.
e.g. if someone does something scary (like edit your userpage) and then everybody thanks you for every edit you've ever done, it's nice if the thank you messages don't hide the important message
I have installed Extension:Echo. Notifying it's ok, but I don't know, what can be set it to allow removing readed messages. User can only do switch between 'read' or 'unread' state.
There is currently no way for someone to explicitly delete notifications. Older read notifications are purged periodically from the database for performance reasons.
Best solution for my wiki was finally change of code in includes/gateway/UserNotificationGateway.php, where I remove item in 'notification_table' instead of writing the timestamp into 'notification_read_timestamp'. Orphaned item remain in the 'event_table', but isn't problem, because may be later cleaned by maintenance script maintenance/removeOrphanedEvents.php
I know that. But here, when I mark a message as read, is probably changed value 'event_deleted' from 0 to 1 in the table Extension:Echo/echo_event table. Because it has this effect for view of the Alerts. In the code is a function „toggleDeleted” that should allow this, but it's not clear to me how and when it is called.
Is there a need to apply the patch for bug T322143 independently if I have downloaded the latest available version of the Echo extension?
If yes, how can the patch get applied manually?
I'm currently implementing changes to how titles are render in notifications. I was wondering why it was decided to truncate titles inside of notifications. I'm thinking about removing the feature because it would make it easier to implement making the page names inside notifications links. Showing the full page name is also critical to distinguishing similar-named named pages, particularly Wikibase entities which can often be similarly-named.
I think truncating titles was a trade off for having longer and more explicit notification text while keeping the whole text not too long.
Back around 2015, notifications used to have links in their text but it was removed in favor of the entire notification being a single primary link with a number of secondary links below and under the "..." menu. This was considered more usable, especially on mobile, by the designers at the time.
I have no opinion about your task specifically, I just wanted to share historical perspective.
I have latest version of mediawiki. Extension installed, and db updated.
Original exception: [7378ff8ac9065fadc602aa86] /wiki/index.php/Main_Page TypeError: Argument 1 passed to MediaWiki\Extension\Notifications\Hooks::onResourceLoaderRegisterModules() must be an instance of MediaWiki\ResourceLoader\ResourceLoader, instance of ResourceLoader given, called in /home/xxx/public_html/medialternatives.com/bedrock/web/wiki/includes/HookContainer/HookContainer.php on line 338
Backtrace:
from /home/xxx/public_html/medialternatives.com/bedrock/web/wiki/extensions/Echo/includes/Hooks.php(186)
#0 /home/xxx/public_html/medialternatives.com/bedrock/web/wiki/includes/HookContainer/HookContainer.php(338): MediaWiki\Extension\Notifications\Hooks::onResourceLoaderRegisterModules(ResourceLoader)
#1 /home/xxx/public_html/medialternatives.com/bedrock/web/wiki/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)
#2 /home/xxx/public_html/medialternatives.com/bedrock/web/wiki/includes/resourceloader/HookRunner.php(48): MediaWiki\HookContainer\HookContainer->run(string, array, array)
#3 /home/xxx/public_html/medialternatives.com/bedrock/web/wiki/includes/ServiceWiring.php(1413): MediaWiki\ResourceLoader\HookRunner->onResourceLoaderRegisterModules(ResourceLoader)
...
When I receive crosswiki notifications, the only place where I can see what they are is the "Recent activity" box. However, this box gets hidden on small screens (both in Vector and in Responsive Monobook). So I can see on my phone that I have notifications, but if I click on them I don't see what they are (if they are from crosswiki). That's clearly not ideal: either merge the crosswiki notifications with the others, or forbid hiding of the selector box, but don't tell me I have messages with no way of telling where they are. See also enwiki VPT post: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&diff=1030694901&oldid=1030691061#Crosswiki_notifications_and_the_responsive_monobook_skin
A workaround is to use .mw-echo-ui-notificationsInboxWidget-sidebar {display:block;} in my skin.css file, but that doesn't look great on small screens either. Could the widget box be moved instead of being hidden completely?
Got the same issue here. And worse, the workaround explained above doesn't seem to work for me.
hello,
In my wiki when the user chose $wgDefaultUserOptions['echo-email-frequency']=1 (so send mail each day) the user doesn't receive but if the user put $wgDefaultUserOptions['echo-email-frequency']=0 (so immediately) he receives the mail, so I have 2 questions.
for each day what time of the day ?
and why don't the user receive?
I test with the Extension:EditNotify maybe it come from here ?
thanks.