I installed a MediaWiki instance on my domain and am trying to edit the MediaWiki:Common.css page, but keep getting an internal error message. Editing regular pages works fine.
I am on MediaWiki 1.3.6 and right now have the site locked down to only registered users with:
$wgGroupPermissions['*']['edit'] = false;
I have tried adding (I am the admin):
$wgGroupPermissions['administrator']['editinterface'] = true;
and:
$wgAllowUserCss = true;
but neither has worked.
Other suggestions welcome. Thanks in advance.
$wgGroupPermissions['administrator']['editsitecss'] = true;
this should be working.
Through process of elimination, it turns out my version of MediaWiki didn't like these lines in the Wikipedia Common.css:
1052 /* Prevent floating boxes from overlapping any category listings,
1053 file histories, edit previews, and edit [Show changes] views. */
Other multi-line comments had the comment indicators /* */ on each line. I updated the lines above to do the same and it worked. I was able to load them on my side.
Related
Situation
I retrieve data from a CSV-source using the external data-extension for mediawiki:
{{#get_web_data:url=http://example.com/names.txt|format=csv|data=name=1}}
{{#display_external_table:template=AddCat|data=1=name }}
The file names.txt simply contains names, one per row.
The template AddCat simply adds the first parameter as category: [[Category:{{{1}}}]]
Problem
The page I use this template on actually shows the name-categories on its bottom but the page itself is not visible on the category-page (I ran the jobs of course).
I assume that this has something to do with the fact that the category-name is not present in the wiki-text but is fetched from an external source.
Any suggestions how I can really add the categories?
The extension has been extensively re-factored since you posted this quesion. The current version adds the page to the categories, in your example, immediately; I've checked.
I recommend that you upgrade the extension and MediaWiki.
Have you looked in CategoryHook?
CategoryHook to which you can add auto-categorisation rules to LocalSettings.php (after including CategoryHook.php--see #Installation). Following is an example which adds articles to Category:Articles containing trees if they have any {{#tree:...}} parser functions in their content.
$wgHooks['CategoryHook'][] = 'wfCategoriseTrees';
function wfCategoriseTrees(&$parser,&$text,&$categories,$sortkey) {
$categories['Articles containing trees']
= array(preg_match('/\\{\\{#tree:/i',$text),$sortkey);
return true;
}
There are several extensions, you may want to try this one
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.
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';
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?