I've added shibboleth authentication (ShibAuthPlugin 1.2.3) to a MediaWiki site (mw 1.17). That turned out to be pretty straightforward, but I now have another related problem: I have two login links. I want only the Shibboleth login link to be available.
I can alter the CSS to hide the unwanted link, but that only makes it invisible. I want to disable it. The documented ways of disabling login links disables all login links. I'm new to MediaWiki and would expect to be able to make this change in the configuration and not have to hack the code to get what I want.
Perhaps someone familiar with MediaWiki can tell me if such a configuration setting exists, or if code modification is the best practice for solving this kind of problem.
Thank you in advance,
Peter
To just remove the login link, I suspect this FAQ entry may help; it seems to be more or less how the Shibboleth auth extension does its own login/logout link mangling. For convenience, let me copy the code here:
$wgHooks['PersonalUrls'][] = 'lfRemoveLoginLink';
function lfRemoveLoginLink( &$personal_urls, $title ) {
unset( $personal_urls['login'] );
unset( $personal_urls['anonlogin'] );
unset( $personal_urls['createaccount'] );
return true;
}
If you want to completely disable local login/logout, even if the user deliberately goes to Special:UserLogin, this solution might do the trick. Again, let me copy the relevant part of the code below:
function LessSpecialPages(&$list) {
unset( $list['Userlogout'] );
unset( $list['Userlogin'] );
return true;
}
$wgHooks['SpecialPage_initList'][]='LessSpecialPages';
Related
I have the following written in a driver:
add_action( 'wp_enqueue_scripts', 'add_css_file' );
function add_css_file()
{
// Tried this prior:
// $path = ABSPATH . "/wp-content/plugins/this_plugin/css/";
// wp_register_style( 'css_file', $path.'css_file.css' );
wp_register_style( 'css_file', 'http://subdomain.mysite.com/wp-content/plugins/this_plugin/css/css_file.css' );
wp_enqueue_style( 'css_file' );
}
The string "css_file" does not appear in the View Source HTML and the CSS rules defined therein do not take effect.
Have you included wp_head() in the <head> of your page? wp_head() will add your queued styles and scripts to the page.
The problem for me lay in the fact that I am modifying the Admin screen rather than the display of a Page or Post to viewers.
Replace:
wp_enqueue_script(...)
With:
admin_enqueue_script(...)
Best of luck.
I have just tried this snippet in my site, and it is working properly. You may get conflict with some other plugin/code.
Also make sure you don't have any Cache enabled, and if so, try to clean up the cache. Also try to clean out your browser cache.
Finally, if non of the above works for you, try to de-activate your plugins, one by one in order to see if some of the plugins conflicts with this function, and in last step try to change theme, also to make sure the current theme doesn't conflict with this function.
I'm using attempting to add an "onclick" object to a page in a singlesite (i.e. rather than multisite) WordPress that triggers an event. The code is:
Send a voice message
When attempting to save the code, WordPress strips the onclick object leaving:
Send a voice message
A user on another forum suggested that this restriction should only apply to multisite non-superadmin users. Again, this is a siglesite with only one admin user.
It is understood that WordPress removes "onclick" from HTML to prevent malicious code. Still, does anyone know how to resolve this?
Thanks.
It appears that with current Wordpress (I'm on 4.9.4), TinyMCE does the filtering directly on the editor screen, not when the form is submitted. The allowedtags and allowedposttags don't seem to matter, so the solution above does not solve the problem for me.
The method I have developed uses the tiny_mce_before_init filter to alter the allowed tags within TinyMCE. The trick is to add the extended_valid_elements setting with the updated versions of the elements allowed for a.
First, look in the page http://archive.tinymce.com/wiki.php/Configuration3x:valid_elements to find the current value for a, which right now is
a[rel|rev|charset|hreflang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur]
And add to the end of that the onclick attribute:
a[rel|rev|charset|hreflang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur|onclick]
Then use that in the filter function like this:
function allow_button_onclick_mce($settings) {
$settings['extended_valid_elements'] = "a[rel|rev|charset|hreflang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur|onclick]";
return $settings;
}
add_filter('tiny_mce_before_init', 'allow_button_onclick_mce');
which you install in your functions.php file in Wordpress. You can see it in action by toggling the text and visual view on the edit page. Without the extended list, the onclick goes away. With it, it remains.
You can solve this by changing the anchor tag into button and adding a script. For more info please refer to this link: Wordpress TinyMCE Strips OnClick & OnChange (need jQuery).
By resolving, I'm assuming you mean to allow the onclick attribute. You will want to be careful with this, because modifying the allowed tags does this for all your users.
You can modify the list of allowed tags and attributes, by adding this to your functions.php file:
function allow_onclick_content() {
global $allowedposttags, $allowedtags;
$newattribute = "onclick";
$allowedposttags["a"][$newattribute] = true;
$allowedtags["a"][$newattribute] = true; //unnecessary?
}
add_action( 'init', 'allow_onclick_content' );
I suggest trying it with only $allowedposttags first to see if that works for you. According to this other stackexchange post, you should only need allowedtags if you need it for comments or possibly non-logged-in users, but when I did something similar in the past, I needed both of them to work.
On a side note, if you want a list of all already allowed tags and attributes, look inside your /wp-includes/kses.php file.
after one hour of browsing I decided to ask this question here.
Is it possible to add css code to an url, for example to change the background color?
Someting kike this: http://yahoo.com (command)style=background-color:#000000;
or similar. Or is it possible to create an url where the site loads with a modified css without using a Chrome extension or similar?
Thanks for help!
No. You can't (using standard software) modify a document by adding anything to that document's URL (unless the server recognises the addition to the URL (e.g. if it was a query string) and returns a different document based on it).
If it was possible then browsers would be exposing every site to XSS attacks.
A browser extension would be the only way to do this client side (but would render users of that extension vulnerable to XSS attacks).
You could also use a bookmarklet in a two stage approach (1. Visit page. 2. Click to activate bookmarket.).
it's possible in a way, but probably not how you imagined it (see Quentin's answer to understand why).
with javascript - note that this is not a 'native' feature so you will have to do a little walk-around. look at the following example:
function get_query_param(name) {
name = name.replace(/[\[]/, "\\\[").replace(/[\]]/, "\\\]");
var regex = new RegExp("[\\?&]" + name + "=([^&#]*)"),
results = regex.exec(location.search);
return results == null ? "" : decodeURIComponent(results[1].replace(/\+/g, " "));
}
window.onload = function() {
var bgcolor = get_query_param('bgcolor');
if (bgcolor.length) {
document.getElementById("xyz").style["padding-top"] = "10px";
document.body.style.backgroundColor = bgcolor;
}
}
now try browsing your page with ?bgcolor=red at the end of the url.
of course that's a demonstration of the main idea, you will have to implement each css property you wish to modify using this approach.
hope that helps.
Yes it is possible. Follow this:
Yahoo
is it possible to create an url where the site loads with a modified css
Solution:
Add something like this : ?v=1.1
<link rel="stylesheet" href="style.css?v=1.1">
When you change the css change the version like this: ?v=1.2 after then your browser will load newly updated css. Note that you can replace to any number each time you change the css.
This will have no effect on the CSS. It will only serve to make the browser think it’s a completely different file.
If you don’t change the value for a while, the browser will continue to cache (or preserve) the file, and won’t attempt to download it unless other factors force it to, or you end up updating the query string value.
I'm trying to restraint editing on the Wiki (using MediaWiki) that I'm creating as an internal project for my company.
We would like to be able to let the page creators specify none or one of the two following options:
Nobody besides the creator of this page can edit the content of this page
Anybody can edit the content of this page, but there must be an approval by the page creator before the changes are visible (whether it'd be by mail, on the wiki directly or something else - does not matter).
If the creator does not specify any of the 2 options, anybody can edit the page, and the changes are immediatly visible (default behaviour).
I've been browsing the net but I did not find an out-of-the-box solution for this. We managed to make some great custom stuff thanks to the edition of the LocalSettings file but not this.
Is there a solution for that functionality?
I don't know of an extension that would make this easy.
What I think you could do would be to take an extension like Flagged Revs or Approved Revs and make it so that instead of using groups as the determiner of approval status, it uses username. This might not be too difficult. Does this make sense?
I had the same problem as you and now i fixed it, here is the solution:
I am using http://www.mediawiki.org/wiki/Extension%3aApproved_Revs for article protection but it didn't fulfil my need it allowed the user to change the currently approved revision of the article and so the change was immediately reflected on the main page so I hacked it a bit, basically you need only one change
go to ApprovedRevs/ApprovedRevs.hooks.php
and find the following code:
static public function setLatestAsApproved( &$article , &$user, $text,
$summary, $flags, $unused1, $unused2, &$flags, $revision,
&$status, $baseRevId ) {
this is a function declaration just after it add the following code:
return false;
and it will work the way you wanted it to be i.e (the change you did will not be reflected until you approve it)
My theme's custom options panel has the following code...
`
/* initialize the site options */
if(get_option('permalink_structure')==""){update_option('permalink_structure', '/%postname%/');}
`
This checks the permalink option setting and since the WP default is "" which triggers the site.com/?p=x handler. This way, if the user has not yet set permalinks from the default, my script does it for them, by setting permalink to post name. Or at least that what I thought...
However, I've had a few folks who have my template tell me that upon first install, they were getting 404 errors on pages.
Apparently, the workaround is to physically navigate to the Permalinks page and just click "Save Changes" (even though when you first hit this page, the Permalink comes up as if it's correctly entered into the "custom" field.
Anyone know why this happens? Is their perhaps another setting in the db that determines the permalink in addition to what happens when update_options() is called as in the above code?
Well, this probably happens because you're updating value in database table (permalink_structure), while .htaccess remains the same, and that's why mod_rewrite isn't loaded and users are getting 404-errors on pages.
I believe WordPress also adds rewriting rules into .htaccess in order to enable permalinks when you're clicking "Save Changes" in admin panel. Let me dig it out and find out what WP is doing exactly.
EDIT.
Ok, here is the code that is doing what you're trying to accomplish:
<?php
if (get_option('permalink_structure') == "")
{
// Including files responsible for .htaccess update
require_once(ABSPATH . 'wp-admin/includes/misc.php');
require_once(ABSPATH . 'wp-admin/includes/file.php');
// Prepare WordPress Rewrite object in case it hasn't been initialized yet
if (empty($wp_rewrite) || !($wp_rewrite instanceof WP_Rewrite))
{
$wp_rewrite = new WP_Rewrite();
}
// Update permalink structure
$permalink_structure = '/%postname%/';
$wp_rewrite->set_permalink_structure($permalink_structure);
// Recreate rewrite rules
$wp_rewrite->flush_rules();
}
wp_rewrite does not appear to have any effect. Users still have to manually click "Save Options" on the permalinks screen.
I suppose I will run firebug on that page during the update to see what's getting set that update_options is apparently missing.
This would appear to be a bug in update_options when the option being updated is permalink_structure.
Anyone disagree?