No edit summary |
No edit summary |
||
Line 290: | Line 290: | ||
<nowiki>// Default |
<nowiki>// Default |
||
$wgtoLateCategoryFiltering = false;</nowiki> |
$wgtoLateCategoryFiltering = false;</nowiki> |
||
+ | |||
− | |||
=== <code>$wgtoLatePageTitleParse</code> === |
=== <code>$wgtoLatePageTitleParse</code> === |
||
This defines if the title of the targets of a page's links should be sent to MediaWiki:To-tooltip-page-name in a request send when the user hovers their mouse over links. |
This defines if the title of the targets of a page's links should be sent to MediaWiki:To-tooltip-page-name in a request send when the user hovers their mouse over links. |
Revision as of 05:06, 25 July 2019
|
Configuration concepts
TippingOver does have a lot of configuration settings and configuration may be quite complex in certain cases. But many of the settings are performance tweaks for users using more advanced setups. Many use cases work just fine with default settings, and other common use cases only require a few setting changes.
Settings that may be of interest for simple use cases include:
$wgtoEnableInNamespaces
|
Determines what namespaces tooltips can be seen in. |
$wgtoNamespacesWithTooltips
|
Determines if a link can have a tooltip based on what namespace it links into. |
$wgtoEnableOnImageLinks
|
Determines if images that are linking to pages will get tooltips. |
$wgtoLoadingTooltip
|
Identifies the page that contains a tooltip to be shown while loading the correct one. |
$wgtoMissingPageTooltip
|
Identifies the page that contains a tooltip to be shown when a tooltip is not created. |
$wgtoEmptyPageNameTolltip
|
Identifies the page that contains a tooltip to be shown when a tooltip-enabled link fails to provide a page name for a tooltip. |
$wgtoEarlyCategoryFiltering $wgtoLateCategoryFiltering
|
For when only some links on a wiki should get tooltips. |
See below for more information on these settings.
Helpful terminology
Some quick TippingOver terminology to help clarify the following setting descriptions:
- Link
- Any portion of page content which TippingOver considers attaching a tooltip to. This may be actual internal links to other pages on the wiki or any content contained within a #tipfor call.
- Target
- For internal links, the target is the page they link to. In other words, where the wiki takes you when you follow the link. In #tipfor calls, the target page is the page title passed as the first parameter.
- Early
- "Early" steps are actions TippingOver performs before a page is even viewed. These will generally happen when a page is saved and any other time the wiki needs to regenerate the page from its wikicode, such as perhaps a template the page uses being edited. Performing actions early has the advantage of avoiding doing the work for each user every time they hover over a link, but in some use cases, might unacceptably degrade the speed of page regeneration resulting in slow loads or even timeouts.
- Late
- "Late" steps are actions TippingOver waits to perform until the user actually hovers over the link with the mouse. This is also commonly referred to as "lazy", such as in "lazy load." This has the advantage of saving these steps until they need to be performed, which also ensures they are performed with current information, but it can slow tooltip loads, since more must be done on mouse-over, and means the work will have to be repeated for every user.
Process overview for attaching and showing tooltips
For configuration, it also helps to have an overview of TippingOver's process for attaching and showing tooltips:
- First, a namespace check is performed on the current page. If it's outside an enabled namespace (see
$wgtoEnableinNamespaces
), TippingOver will stop doing anything on that page. - Second, optionally, an lookup index is built for the category filter. (See
$wgtoPreprocessCategoryFilter
.) - Then, for each link during the early stage, the following steps are performed except when disabled (see
$wgEnableOnImageLinks
for including or excluding image links):- Target page namespace check. See
$wgtoNamespacesWithTooltips
. - Early target redirect follow. See
$wgEarlyTargetRedirectFollow
. - Early category filtering. See
$wgEarlyCategoryFiltering
,$wgEnablingCategory
, and$wgDisablingCategory
. - Early page title parse. See
$wgEarlyPageTitleParse
and$wgtoAssumeNonemptyPageTitle
. - Early exists check. See
$wgEarlyExistsCheck
. - If no early checks prevent it, a tooltip is attached.
- Target page namespace check. See
- Finally, for each link that has a tooltip attachment, the following steps, if enabled or not completed early, happen when the user mouses over the link:
- Possibly show a loading tooltip now. See
$wgLoadingTooltip
. - Late target redirect follow. See
$wgLateTargetRedirectFollow
. - Late category filtering. See
$wgLateLateCategoryFiltering
. - Late page title parse. See
$wgLatePageTitleParse
and$wgtoAssumeNonemptyPageTitle
. - Late exists check. See
$wgLateExistsCheck
. - Possibly show a loading tooltip now if not up already. See
$wgLoadingTooltip
and$wgAllowTwoRequestProcess
. - Actually load the tooltip. See
$wgMissingPageTooltip
and v$wgEmptyPageNameTooltip for alternatives when there's no tooltip to load.
- Possibly show a loading tooltip now. See
Settings below are listed in the order in which they become relevant to the above process.
Configuration settings
At present, editors must send a request to their wiki manager to change any of the following settings.
$wgtoEnableInNamespaces
This defines what namespaces tooltips are actually displayed in. When viewing pages in namespaces where this is set to false
, no internal links on the page will display tooltips.
// Default $wgtoEnableInNamespaces = Array( NS_MAIN => true, NS_TALK => false, NS_USER => true, NS_USER_TALK => false, NS_PROJECT => true, NS_PROJECT_TALK => false, NS_IMAGE => false, NS_IMAGE_TALK => false, NS_MEDIAWIKI => false, NS_MEDIAWIKI_TALK => false, NS_TEMPLATE => false, NS_TEMPLATE_TALK => false, NS_HELP => false, NS_HELP_TALK => false, NS_CATEGORY => true, NS_CATEGORY_TALK => false, );
$wgtoPreprocessCategoryFilter
This defines how TippingOver should perform early category filtering if it is enabled in $wgtoEarlyCategoryFiltering
. This setting is just for performance tweaking and can likely be left alone if the wiki doesn't appear to be suffering from performance issues.
Valid values are:
true
|
This pre-fetches the page IDs within the relevant category and all of its subcategories and performs the filtering while the page is loading. This allows category filtering to then be done with a very quick lookup as each link is processed. The downside is that it must fetch all page ids from the relevant category hierarchy, so if it's complex or has a huge number of pages, this could be an unnecessary performance hit on the wiki. But in most cases, it's probably more performant than the alternative. |
false
|
This performs the category filtering while the page is loading as each link is processed. It must check the database for every new page it encounters, though, which may noticeably slow down the loading of link-heavy pages, but may be a better option if the relevant categories have complex hierarchies or a large number of pages since this doesn't require fetching all of the page ids from the categories. |
If both options seem to be dragging down the wiki, consider disabling $wgtoEarlyCategoryFiltering
and check out $wgtoLateCategoryFiltering
instead.
// Default $wgtoPreprocessCategoryFilter = true;
$wgtoEnableOnImageLinks
This defines whether or not tooltips are enabled on image links. In most cases, this refers to links that would be created by something like [[File:Example.jpg|link=Example]]
. It can even be possible, in certain configurations, for the images themselves to have tooltips, so even a link like [[File:Example.jpg]]
could potentially show a tooltip if this is enabled.
Valid values are:
true
|
Tooltips are enabled on image links, so if an image links to a page with a valid tooltip, it will show up when hovering over the image. |
false
|
Tooltips are disabled on images links and won't show up even if the image links to a page with a valid tooltip. |
// Default $wgtoEnableOnImageLinks = true;
$wgtoNamespacesWithTooltips
This defines which internal links to which namespaces will have tooltips enabled Links to pages in namespaces where this is set to false
, or which do not appear in the array, will not have tooltips displayed.
// Default $wgtoNamespacesWithTooltips = Array( NS_MAIN => true, NS_TALK => false, NS_USER => true, NS_USER_TALK => false, NS_PROJECT => false, NS_PROJECT_TALK => false, NS_IMAGE => false, NS_IMAGE_TALK => false, NS_MEDIAWIKI => false, NS_MEDIAWIKI_TALK => false, NS_TEMPLATE => false, NS_TEMPLATE_TALK => false, NS_HELP => false, NS_HELP_TALK => false, NS_CATEGORY => false, NS_CATEGORY_TALK => false, );
$wgtoEarlyTargetRedirectFollow
This defines whether TippingOver follows redirects in link or #tipfor
targets before early category filtering and early page title parsing.
Valid values are:
false
|
The target page will be used for early category filtering and the early page title parse whether it is a redirect or not. This can be expected to run a little faster, as it skips an extra database check for each link, though it may only be noticeable on link-heavy pages. It also means that if category filtering is going to filter based on the categories that page is in, even if it's a redirect.
Redirect following can still be done late (see |
true
|
If the target page is a redirect, than its destination page is treated as the target page in all subsequent steps, early or late. |
// Default $wgtoEarlyTargetRedirectFollow = true;
$wgtoEarlyCategoryFiltering
This defines if the target page of links should be checked to see if they are in the hierarchy of a tooltip-enabling or disabling category when the links are generated.
Valid values are:
false
|
No category check will be done during link generation, leaving the tooltip "enabled" at least until the user hovers over the link with the mouse. The value of $wgtoLateCategoryFiltering will determine if category filtering is performed then.
|
true
|
This will check the target page of a link against an enabling or disabling category, which may result in the tooltip of that link being disabled. See $wgtoEnablingCategory and $wgtoDisablingCategory for how this works. Also, see $wgtoPreprocessCategoryFilter to change the approach TippingOver uses to make this check. |
// Default $wgtoEarlyCategoryFiltering = false;
$wgtoEnablingCategory
Only applies if $wgtoEarlyCategoryFiltering
and/or $wgtoLateCategoryFiltering
are set to true
.
When those settings are applied, a link only gets a tooltip when its target page is in the category defined by this setting or one of its subcategories. The Category: namespace is optional when defining the category in this setting.
Setting this to null
or an empty value will cause category filtering to use the disabling category in $wgtoDisablingCategory
instead. In the current version, only one or the other operates at any given time, but a future version may allow both to function simultaneously.
// Default $wgtoEnablingCategory = "Has tooltips enabled";
$wgtoDisablingCategory
Only applies if $wgtoEarlyCategoryFiltering
and/or $wgtoLateCategoryFiltering
are set to true
and $wgtoEnablingCategory
is set to null
or an empty value.
When those settings are applied, a link will not get a tooltip when its target page is in the category defined by this setting or one of its subcategories. The Category: namespace is optional when defining the category in this setting. But pages outside that category hierarchy do; it functions exactly opposite of $wgtoEnablingCategory
.
In the current version, if there is an enabling category, the disabling category won't be used. In a future version, however, they may be set up to work together as follows: links would have their tooltips disabled if either the target page was in the disabling category hierarchy somewhere or not in the enabling category hierarchy somewhere. In other words, the disabling category will have priority when a target page is in both hierarchies.
// Default $wgtoDisablingCategory = "Has tooltips disabled";
$wgtoEarlyPageTitleParse
This defines if the title of the targets of a page's links should be sent to MediaWiki:To-tooltip-page-name to find the values whenever the page is recached on the server side.
Valid values are:
true
|
This performs the parse while the page is saved, purged, or otherwise recached on the server, saving some processing when actually loading tooltips at the expense of adding overhead to page parsing. How much of an impact this will have will depend a lot on the logic in MediaWiki:To-tooltip-page-name. Expensive processing in that function could present a danger of causing link-heavy pages to time out when the wiki attempts to parse them, but there are tradeoffs to doing the check late. |
false
|
This will not perform the page title parses during page saves, purges, or recache operations. Note that if $wgLatePageTitleParse is also set to false, this effectively disables the extension in its current state. (Some features being considered for future versions would provide options for tooltips that would not require page title parsing to function, but at present, it is still a requirement for all tooltips.)
Cases where early page title parsing could potentially cause performance issues and timeouts would include MediaWiki:To-tooltip-page-name using expensive functions like |
// Default $wgtoEarlyPageTitleParse = true;
$wgtoAssumeNonemptyPageTitle
This determines if TippingOver should assume MediaWiki:To-tooltip-page-name will always return a page name.
Valid values are:
true
|
This will disable the empty page tooltip defined by $wgEmptyPageNameTooltip even if it set, so no tooltip is shown if MediaWiki:To-tooltip-page-name should return an empty value.
Warning: As the name suggests, this causes TippingOver to assume MediaWiki:To-tooltip-page-name won't return an empty page name. When See |
false
|
This causes TippingOver to assume MediaWiki:To-tooltip-page-name may return an empty value, and so $wgtoEmptyPageNameTooltip is enabled if valid. Additionally, when late page title parsing (see $wgtoLatePageTitleParse ) is performed while there's a valid loading tooltip but no valid empty page tooltip, the loading tooltip will be automatically disabled unless $wgtoAllowTwoRequestProcess is set to true, which is not generally recommended.
|
// Default $wgtoAssumeNonemptyPageTitle = false;
$wgtoEarlyExistsCheck
This defines whether or not a check is made that the page identified by processing MediaWiki:To-tooltip-page-name exists for the given target page of a link during an early page title parse.
Valid values are:
false
|
This disables the exists check during early page title parses. This is useful if the logic in MediaWiki:To-tooltip-page-name is guaranteed to return an empty value if the tooltip page doesn't exist, or it has its own logic for determining the correct default page to use. This option then prevents redundant processing that could slow down page or tooltip loading.
It may also simply be desirable to delay the check (see Disabling both this and |
true
|
This performs the exists check during page saves, purges, and other recaches, saving a slight bit of processing when actually loading tooltips at the expense of adding some extra processing for links during
page recaching. This requires an early page title parse first for TippingOver to know what page to check, thus setting $wgtoEarlyPageTitleParse to false effectively disables this as well. |
// Default $wgtoEarlyExistsCheck = true;
$wgtoLoadingTooltip
This defines what page, if any, to use as a loading tooltip. In other words, this is what will be displayed while the actual tooltip for the page is being requested from the server. To disable loading tooltips completely, set this to null
or an empty value. The loading tooltip is displayed while waiting for the server to return the requested tooltip after a user hovers over a link.
This can also be disabled by blanking or deleting the page in question, though this is slightly less efficient as there is more overhead involved in checking that, but it does allow it to be enabled more easily later on.
Important note: In some situations, the loading tooltip may be automatically disabled. This occurs in some cases when various early checks are disabled, leaving TippingOver in a situation where it doesn't yet know whether there is a tooltip to show. Rather than show a loading tooltip and then nothing, it just tries to load the tooltip instead. This behavior can be changed by setting $wgAllowTwoRequestProcess
to true
, but this isn't recommended. See $wgAllowTwoRequestProcess
below for more information.
// Default $wgtoLoadingTooltip = "MediaWiki:To-loading-tooltip";
$wgtoLateTargetRedirectFollow
This defines whether TippingOver follows redirects in link or #tipfor
targets when the user mouses over a link with the tooltip attached.
Important note: This only applies to links to which no early target redirect following, no early category filtering, no early page title parse, and no early exists check has been applied. Any of those steps being completed on a link causes this step to be bypassed for that link, regardless of the setting.
Valid values are:
false
|
This setting means that the late category filter check and page title parse will operate on the exact page specified as a link or #tipfor target, even if it's a redirect, unless early redirect following, per $wgtoEarlyTargetRedirectFollow was performed.
|
true
|
If the target page is a redirect, then the destination page will be the target used for late category filtering, page title parsing, and exists checks. |
// Default $wgtoLateTargetRedirectFollow = true;
$wgtoLateCategoryFiltering
This defines if the target page of links should be checked to see if they are in the hierarchy of a tooltip-enabling or disabling category when the user hovers over the links.
Valid values are:
false
|
No category check will be done when the user hovers their mouse over the link, even if no check had been performed earlier. Thus category filtering is completely disabled if both $wgtoEarlyCategoryFiltering and this setting are false .
|
true
|
Assuming it hasn't been done already (see $wgtoEarlyCategoryFiltering ), this will check the target page of a link against an enabling or disabling category, which may result in the tooltip of that link being disabled. See $wgtoEnablingCategory and $wgtoDisablingCategory for how this works.
This can increase wiki performance since the category checks are only performed as needed, but see It may also increase the number of requests TippingOver sends to the server since it may do so when the user hovers over links where the tooltip should be disabled anyway. This is probably not a significant concern, but regardless, early category filtering has a mild advantage in this respect. Early and late category filtering can be enabled at the same time. In the current version, this will prevent late category checks from happening at all since TippingOver does not repeat the process when an early check has already been performed. Potential upcoming features may create cases where only some of the links get an early check, so if early category checking is used, it is normally best to leave this set to |
// Default $wgtoLateCategoryFiltering = false;
$wgtoLatePageTitleParse
This defines if the title of the targets of a page's links should be sent to MediaWiki:To-tooltip-page-name in a request send when the user hovers their mouse over links.
Valid values are:
true
|
This performs the parse after the user movses over a link during the actual tooltip load, assuming this hasn't already been done as described above for $wgtoEarlyPageTitleParse . See $wgtoLoadingTooltip for some potential issues to watch out for in these delayed parses, however.
In the current version, when |
false
|
This will not perform the page title parses when hovering over links even if it wasn't done in an early parse. In the current version, setting $wgtoEarlyPageTitleParse to false as well will result in page title parsing being effectively disabled, which effectively disables the extension.
|
// Default $wgtoLatePageTitleParse = true;
$wgtoLateExistsCheck
This defines whether or not a check is made that the page identified by processing MediaWiki:To-tooltip-page-name exists for the given target page of a link during an late page title parse triggered by the user hovering their mouse over a link.
Valid values are:
false
|
This disables the exists check during late page title parsing. As with $wgEarlyExistsCheck , this may be desirable if the logic in MediaWiki:To-tooltip-page-name cannot return a title for a page that doesn't exist, thus preventing a redundant or unnecessary check.
But if |
true
|
This performs the exists check after the user movses over a link during the actual tooltip load. This may be a good idea if pages are particularly link heavy and category filtering isn't an option or doesn't significantly reduce the number of links to check. |
// Default $wgtoLateExistsCheck = true;
$wgtoAllowTwoRequestProcess
The "two request process" is where TippingOver makes one request to the server just to determine if there is a tooltip, and then if there is, another request to actually load it.
If allowed by this setting, TippingOver will only use this process if a loading tooltip exists and any of these configurations are specified:
$wgtoEarlyPageTitleParse
isfalse
and$wgtoLatePageTitleParse
istrue
with no valid empty page name tooltip unless$wgAssumeNonemptyPageTitle
is set totrue
(but see risks with that setting),$wgtoEarlyPageTitleParse
isfalse
and$wgtoLatePageTitleParse
is true with no valid missing page tooltip unless $wgtoEarlyExistsCheck and $wgtoLateExistsCheck are both false (but see risks with that situation),$wgtoEarlyExistsCheck
isfalse
and$wgtoLateExistsCheck
istrue
with no valid missing page tooltip, or$wgtoEarlyCategoryFiltering
isfalse
and$wgtoLateCategoryFiltering
istrue
under any circumstance.
When disallowed, TippingOver quietly and automatically disables the loading tooltip instead and just proceeds with a single request to fully load the tooltip (or quietly stop if there's nothing to show).
Disallowing the two request process is default, as permitting it is not recommended. It takes approximately twice as long to load a tooltip this way, and showing the loading tooltip is delayed because TippingOver will wait for the response to the first request so it doesn't show the loading tooltip when there will be no tooltip to show. (The single exception is explained with the $wgtoAssumeNonemptyPageTitle setting description.) But if showing a loading tooltip is strongly desired even in the above configurations, this process is available.
Valid values are:
false
|
Don't allow the two request process and disable the loading tooltip if necessary to avoid it. |
true
|
Allow the two request process, leaving the loading tooltip enabled in all configurations if it exists. |
// Default $wgtoAllowTwoRequestProcess = false;
$wgtoMissingPageTooltip
This defines what page, if any, to use as a tooltip if the page identified by processing MediaWiki:To-tooltip-page-name doesn't exist. To disable this entirely, set this to null
or an empty value.
This can also be disabled by blanking or deleting the page in question, though this is slightly less efficient as there is more overhead involved in checking that, but it does allow it to be enabled more easily later on.
Warning: See warning under $wgtoLoadingTooltip
below before disabling this in any way.
// Default $wgtoMissingPageTooltip = "MediaWiki:To-missing-page-tooltip";
$wgtoEmptyPageNameTooltip
This defines what page, if any, to use as a tooltip if processing MediaWiki:To-tooltip-page-name results in an empty value being returned. To disable this entirely, set this to null
or an empty value.
This can also be disabled by blanking or deleting the page in question, though this is slightly less efficient as there is more overhead involved in checking that, but it does allow it to be enabled more easily later on.
Warning: See warning under $wgtoLoadingTooltip
below before disabling this in any way.
// Default $wgtoEmptyPageNameTooltip = "MediaWiki:To-empty-page-name-tooltip";
|