We have a Mediawiki installation at our company. The original Wiki admin has left. I don't know who has admin rights or the admin username and password.
I only have user rights on the wiki.
Goal: To change h2 headers, and the .mw-headline class, to have an underline when the page is printed.
I've searched Google and MediaWiki help and found I have to make a link to and edit User:Chuck/Print.css.
On one of my Mediawiki pages I've tried to make a link to [[User:Chuck/Print.css]], edited and saved it, but the changes don't take effect.
I don't know if the variable $wgAllowUserCss = true; is set because I only have Wiki 'user' rights.
What can I do to get the Print.css to work?
Thank you for your help.
There are two meanings of "admin": the one who is given a role administrator in the MediaWiki website, and the one who controls database and the server. I don't know which one were you referring to (it is also possible that both are the same person).
Assuming that $wgAllowUserCss = false;
Then, if you managed to find someone who can access the server, you could ask that person to edit LocalSettings.php so that $wgAllowUserCss = true;, and now your User:Chuck/Print.css will work. Note that it is absolutely impossible to make your User:Chuck/Print.css work while $wgAllowUserCss = false;.
Otherwise, if you managed to find someone who is given a role administrator, and it is okay to make your change to Print.css systemwide, you can ask the administrator to edit MediaWiki:Print.css. This guarantees to work even when $wgAllowUserCss = false;.
Usually there could be more than one user who are given the role administrator. You could see the list of administrators by going to the page Special:ListUsers. For example, here's all administrators in English Wikipedia: https://en.wikipedia.org/w/index.php?title=Special%3AListUsers&username=&group=sysop&limit=50
Please also note that if you can access the database, you can give a role administrator to a user in the website via the database too.
Assuming that $wgAllowUserCss = true;
It is also possible that in fact $wgAllowUserCss = true;, but the change doesn't take effect. Read https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache for the solution.
Note: without an admin (in both meanings), pages cannot be deleted, and a lot of system changes cannot be done. Your company wouldn't be able to stay in this state forever. Perhaps you should ask your company to install a new wiki.
Related
I have 2 different roles with exactly the same permissions and text formats when I switch a user between these two roles with the first one I can edit one specific node but not with the second, is there something I'm missing? I basically want to make these two roles to work exactly the same and after that I will add/remove some permissions.
I even tried using the direct edit URL "node/XXXXXX/edit" with no success on my 2nd role, as soon as i swap to the 1st role I can access the edit page.
On the content type I looked on the User Permissions and both of them are checked on the "Roles that can EDIT any content of this type"
As suggested on one of the answers I re created the role and cleared the cache but with no success.
Do both roles have the right permissions to work with the text format?
/admin/config/content/formats
or go to Configuration > Content authoring > Text formats
Try to delete the second role;
Create again and
Clean cache.
That happened to me time ago.
Hope that helps.
I have a group of users that will be using a web database.
Ideally, I would like these users to view that website with some user styles of our creation (so that some of the website elements are displayed differently, like highlighting fields they need to fill out). These users are independent and remote, meaning that we can't really access their computers to do anything to set this up (like setting up Stylish for them).
I was wondering if we could somehow create a package that will display the website using such stylesheet, as if it was an application rather than a website that they visit with their browser.
The idea would be that by opening this "app" they're actually opening a dedicated browser window to this webpage where they can interact with it, can't navigate away (just no address bar), and uses this stylesheet I mentioned. Thus the "as if it was an app".
I hope I was sufficiently clear. I don't even know what this would be called (not even what tags to use), so my research has really taken me nowhere. Guidance on how to get this done will be highly appreciated. If somebody has a better idea of how to obtain a similar result, I'll be happy to experiment!!
Thanks!
Will the users be logging in through user accounts in your database?
If so, create a column in the user database which, should it return a certain value (say true for these special users and false for all else) then a different stylesheet is used.
I'm dealing with this matter since a while, I have read a ton of articles and stuff out there but I couldn't find a place that shows the RIGHT way, standard, correct, whatever you like to call it, to prevent access to my wp-admin or wp-login.php
On all Wordpress sites I see (the well made ones) you will never see anything if you type thesite.com/wp-admin
As I could see, one way to do this is by restricting the access to that folder by creating an .htaccess file and restrict by IP the access to the folder. Seems to be the "cleanest" way to do. What I'm not sure about it is that I have a dynamic address provided by my ISP, so on a certain time my IP will change, that will force me to also change the .htaccess to my new address, I don't see that practical. I can set a range also, but by doing that I will also authorize access to all people within that range of IPs (other clients of my ISP for example).
I'm then struggling to find the best/standard way to do this.
Anyone can help me?
Thanks
From this Codex discussion - this blog article claims to provide a solution for renaming wp-admin. I haven't tested it, but it does seem to have worked for people.
However,
This hack has its drawbacks.
The “edit” link on your posts will no longer work. You may want to remove it from your theme.
The admin link on your side bar will no longer work. You may want to remove it from your theme.
The standard login link will no longer work. Instead, use a bookmark as it will redirect you back to your hidden login page after you finish logging in.
As an alternative, there's also the option of adding an Apache .htaccess password dialog on top of the wp-admin login. That won't hide it, but it will provide another (albeit annoying) layer of security.
I'm not aware of a good .htaccess way to limit access IP-wise if you have a dynamic IP, or want to access the site from different networks.
I think it would be possible to work your way around the drawbacks described above by adding filters for admin_url (or possibly even site_url if you just check the $path parameter).
This is pretty much untested but will probably be a good starting point:
function my_admin_url($url = null, $path = null, $blog_id = null) {
// This our `wp-admin` replacement
// probably wiser to use a filter/function for this, so that you can
// do it dynamically by checking for the actual directory or something
$custom_admin_dir = 'my-admin';
// Remove filename.php
if (!empty($path))
$url = dirname($url);
// Remove wp-admin
$url = dirname($url);
// Build up a new URL
$url = trailingslashit(trailingslashit($url) . $custom_admin_dir) . $path;
return $url;
}
add_filter('admin_url', 'my_admin_url', 10, 3);
Also, if your on a network site you might want to take the $blog_id parameter into account and/or do the very same thing for the network_admin_url filter.
There is an article on how to secure wp-admin. It also has its drawbacks, since it gets overwritten every time you update wordpress, but it gets the job done.
I'm using the subsites module to make a multi site system.
I'd like the users logins to the sites to be independent. So if a user has registered on one site, they can't just go to another subsite and login - they have to register for that site too.
In other words - registrations on each subsite is completely independent.
Is this possible?
Technically it would be possible to write a DataObjectDecorator for the Member class, and add a SubsiteID to each member, and then add a filter for that SubsiteID with argumentSQL().
And you need to modify the register form to consider the SubsiteID and hook into the authenticator.
But could very well be that there are a couple of other points you need to hook into to get this to work.
So yes, it should be possible, but it is going to take a long time, and it will be a pain in the arse to get it working properly.
you should carefully consider if you really need it that bad that you need to go this way.
It should be possible to just work around this by using groups, and setting group permissions.
I know this is pretty old thread, but in case someone stumble upon this thread, it will be useful.
There is another hack for this.
/mysite/extensions/CustomLeftAndMain.php
<?php
class CustomLeftAndMain extends Extension {
public function onAfterInit() {
self::handleUser();
}
public static function handleUser(){
$currentSubsiteID = Subsite::currentSubsiteID();
$member = Member::currentUser();
$memberBelongsToSubsite = $member->SubsiteID;
if($memberBelongsToSubsite>0 && $currentSubsiteID!=$memberBelongsToSubsite){
Security::logout(false);
Controller::curr()->redirect("/Security/login/?_c=1001");
}
}
}
and in /mysite/_config.php add an extension
LeftAndMain::add_extension('CustomLeftAndMain');
What above code basically does is, the system lets user login no matter which subsite they belong to. And as long as application is initiated, whether the logged in user belongs to current website or not (method handleUser does it.).
If user doesnot belong to current site, then they are logged out and then redirected to login page.
The description says (among other things):
"The subsites module allows multiple websites to run from a single installation of SilverStripe, and share users, content, and assets between them."
"The branches can have separate users/admins, and information that is individual."
If you don't have a common "headquarter", I'm not sure the module is right for you. Instead of hacking the module to do something it isn't intended to do, why not make separate installations?
I have come across this problem in the past but never solved it.
I am on the verge of finishing a Drupal site for a client. I created two content types and gave him the permissions necessary to edit any occurrence of these node types.
The strange problem is the client can edit any node of type product_type except for one particular node of the same type.
So in other words, all nodes of type product_type are editable except node/3.
Do you have a node access module installed, like Content Access or Taxonomy Access Control? If you do, it could be that there are per-node permissions set and your client's role doesn't have permission to edit that node, or it could be that it is tagged with a particular taxonomy term which prevents him from editing it.
If you don't have any extra node access modules installed, is it just that the link to "Edit" is missing in the tabs section of the page? Can the client type in "http://example.com/node/3/edit" and reach the edit screen that way?
If you supply an answer to these questions in the comments, I'll edit this answer as best I can.
Check the author of the node. If it's different than the client's user account that may account for the problem. If that does not work you may need to "rebuild permissions."
I found out what the issue was. The client account could not edit anything with full-html input format.
I enabled that at /admin/settings/filters and it works just fine now.
Thanks for looking in.