This is a feature request (more a call for discussion of for a new feature).
The main idea is to set a date range for a wiki page when it should be visible.
When comparing the features of SMW to other open source CMS like Drupal, Wordpress or Typo 3, there is one very basic feature that is missing in MediaWiki: the opportunity to hide/show content in general (hiding content is possible, best achived afaik with the lockdown extension using namespaces) and specifically hiding showing content from a certain start end date.
The very simple use case is that you use SMW to create news items for a website with several properties. E. g. news date, author, topic etc. You can very well use a property "visible on main page" or "visible from ... to".
Then you could display news items on the main page only if the have the visibility option property set or only if they are within the date property range.
However, content that should not be visible (yet) can only be hidden on the predefined ask queries on the main page. The content will show up when you search for it or use ask queries without putting the date restirction as search terms.
A pre-defined property "visible from" and "visible to" could be implemented that would result in a page only being visible to anonymous users if the requirements are met. Logged in users can see and edit the content.
Maybe it would be feasible to use the lockdown/namespace approach: the page "Semantic MediaWiki 3.2 is released" is first created in a restricted namespace (e. g. as page "Restricted:Semantic MediaWiki 3.2 is released".
When a certain restriction criterion is met (or not met any longer), SMW moves the page to a namespace that is not restricted: so from "Restricted:Semantic MediaWiki 3.2 is released" to "Semantic MediaWiki 3.2 is released" (in the main namespace).
I know that this request has a lot to do with user rights and hiding content in general. But I am not talking about this, I am comparing this to the feature of "show on start page" and "show from" "show until" that is available in most CMS, because the have a front end and back end.
Maybe some king of "backend" could be implemented with a special page that shows "hidden" content that is not yet published as an alternative approach?
Any thoughts on this?
Hmm, can't this be done by annotating regular properties and add them to the query. The display of the news item on the respective news item page could be controlled with the User Functions extension?
Anyhow, this would be something for a separate extension.
A couple of notes:
The main idea is to set a date range for a wiki page when it should be visible.
I get the gist of the request and to be upfront clear, manipulating
content visibility is not a core feature of SMW. In the widest sense
of interpretation it deals with transformations of data it has
knowledge of but arbitrary content certainly doesn't count towards
that.
Anyhow, this would be something for a separate extension.
So, yes, if at all this should be a separate extension something like
SemanticContentExpiration.
SMW moves the page to a namespace that is not restricted: so from "Restricted:Semantic MediaWiki 3.2 is released" to "Semantic MediaWiki 3.2 is released" (in the main namespace).
Moving content across NS borders seems like a bad idea as you would
loose revision (history) information about an entity (aka. wikipage).
Any thoughts on this?
I added some some technical notes in case someone wants to implement
this as part of an extension.
If you wanted to "hide" the entire content of a page you could achieve
this by doing something like:
Hooks::register( 'BeforePageDisplay', function( &$outputPage, &$skin ) {
$title = $outputPage->getTitle();
if ( $title->isSpecialPage() || $title->isRedirect() ) {
return true;
}
$isExpired = true;
// Here you check your properties and come to
// the conclusion whether the content is expired or not
// ...
if ( $isExpired ) {
// Clears the visible body text
$outputPage->clearHTML();
// Removes the category links
$outputPage->setCategoryLinks( [] );
$outputPage->prependHTML( "Content isn't shown because it has expired." );
}
} );
You would want to introduce a new parser function that lets you
control the output within a page.
{{#content_expiration: < content expected to be displayed >
|start=
|end=
}}
You want to use the TitleQuickPermissions (or any other permission
related) hook to block access to expired content on actions like diff,
edit, raw etc.
There are different approaches on how to prevent subjects that are
expired to hide from results without forcing each and every query to
add your specific expiration properties such as "show on start page"
and "show from" "show until". Of course, the post-processing via
AfterQueryResultLookupComplete would alter the limit/offset in terms
of what was selected and what is displayed.
Hooks::register( 'SMW::Store::AfterQueryResultLookupComplete',
function( $store, &$queryResult ) {
foreach ( $queryResult->getResults() as $subject ) {
// Filter those subjects that have a known expiration to
// prevent annotations to be displayed
}
} );
Another approach would be to use
SMW::Store::BeforeQueryResultLookupComplete to manipulate the
"original" query and add additional conditions before the query is
executed.
Mentioned notes are for inspiration and should not be taken without
further review, implementing the requested functionality requires more
than above but at least should provide an idea about the technical
direction.
Cheers
On 2/11/20, Karsten Hoffmeyer notifications@github.com wrote:
Anyhow, this would be something for a separate extension.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4534#issuecomment-584214673
@krabina I tried to answer your request, Does it answer your questions? Is something missing? otherwise can we close this, or? @kghbln I'm leaving this ticket to you if no other technical questions arise.
Lets wait for @krabina his reply before closing.
He replied with a rocket days ago. What is needed now is a new extensions. No need to let this rot as an open idea for pick-up.
This is looking great. Now we need to find somewone to implement and possibly fund this...
Therefore I would suggest to move that to enhancement or open idea and not just close it. It will be forgotten this way.
Now seeking a developer in the Enhancements and features project.
Most helpful comment
A couple of notes:
I get the gist of the request and to be upfront clear, manipulating
content visibility is not a core feature of SMW. In the widest sense
of interpretation it deals with transformations of data it has
knowledge of but arbitrary content certainly doesn't count towards
that.
So, yes, if at all this should be a separate extension something like
SemanticContentExpiration.Moving content across NS borders seems like a bad idea as you would
loose revision (history) information about an entity (aka. wikipage).
I added some some technical notes in case someone wants to implement
this as part of an extension.
Hide all
If you wanted to "hide" the entire content of a page you could achieve
this by doing something like:
Hide some
You would want to introduce a new parser function that lets you
control the output within a page.
Protect expired content
You want to use the
TitleQuickPermissions(or any other permissionrelated) hook to block access to expired content on actions like diff,
edit, raw etc.
Query display
There are different approaches on how to prevent subjects that are
expired to hide from results without forcing each and every query to
add your specific expiration properties such as "show on start page"
and "show from" "show until". Of course, the post-processing via
AfterQueryResultLookupCompletewould alter the limit/offset in termsof what was selected and what is displayed.
Another approach would be to use
SMW::Store::BeforeQueryResultLookupCompleteto manipulate the"original" query and add additional conditions before the query is
executed.
Mentioned notes are for inspiration and should not be taken without
further review, implementing the requested functionality requires more
than above but at least should provide an idea about the technical
direction.
Cheers
On 2/11/20, Karsten Hoffmeyer notifications@github.com wrote: