Posted 2 years ago #
Seriously, lacking the following OBVIOUS controls to render this addition less than obnoxious;
Setting in admin area to globally disable without modifying a theme
Controls to disable admin bar for users BY ROLE - who really wants all SUBSCRIBERS having an un-styled admin bar atop the site?
Posted 2 years ago #
Setting in admin area to globally disable without modifying a theme
http://wordpress.org/extend/plugins/disable-admin-bar/
Controls to disable admin bar for users BY ROLE - who really wants all SUBSCRIBERS having an un-styled admin bar atop the site?
That is a cool idea :) You wanna write it?
Posted 2 years ago #
I began very shortly after posting. I'm working on a plugin that will;
add a menu in the admin area for admin bar control
allow the plugin to be active/inactive
have a master "disable admin bar" option
have master disables for admin pages and public pages
and per role:
enable/disable admin bar in admin,
enable/disable admin bar in public pages
allow the profile settings to over-ride the previous 2 or not
Its functional with settings twiddled in the PHP at the moment (so all the querying of current user and current role etc is done), tomorrow I will be tackling the DB storage and admin page construction.
Given the number of clients I maintain WP sites for, I have no real choice; a significant number of them are going to flip out when they update and their users start questioning the random grey bar that appears.
Posted 2 years ago #
The grey bar looks good on my site. BUT, it more or less mimics some of features already there.
Ex: The new admin bar has search engine, but right below it I already have Google Custom search bar.
Does anyone know whether the admin bar search engine is an improvement over old WordPress search engine, or is it same?
Posted 2 years ago #
As I also noted in a topic directly asking for a recall of that ridonkulous thing: it's an abomination and it must go.
Posted 2 years ago #
@nv1962
Per the first reply in this thread:
http://wordpress.org/extend/plugins/disable-admin-bar/
install, activate... admin bar gone.
Posted 2 years ago #
Oh, I solved it more trivially: just back-grade to WP3.0.5 - no extra and inherently redundant overhead causing plugin needed.
Problem solved! :-)
Posted 2 years ago #
Rock on! You will make a lot of people very happy.
FYI, if you put http://wordpress.org/extend/plugins/disable-admin-bar/ in a folder called mu-plugins (yes, you can do this on Single Site as well as MultiSite) then your clients won't be able to un-install it unless they go in via FTP. Just put the mu-plugins folder in the same level as themes and plugins (wp-content/mu-plugins) and copy the FILE (not the folder) for the plugin into there. Done.
Posted 2 years ago #
That's nice, however I think its worth noting (in a more calm manner than in that other thread) why the manner of this feature being added was mishandled:
(Due disclosure; having had to spend Wednesday evening and ongoing a chunk of today fashioning a band-aid to plaster over the gaps in this release has not...improved my mood.)
I'm not a guy who runs 'a blog' - its my job to install, customise and maintain over time my company's clients' blogs (and other sites using WP as a CMS). It would be a serious mistake to assume that these sites share hosting, and therefore that I could be using WP_MU to create a common environment.
Therefore; any fix to remove / control this feature has to be repeated N times for N customer sites. (Not a happy camper at this point)
Not all clients are simply going to simply say "begone with it", so the shotgun approach from Ozh is insufficient.
Most of my clients, however, are not going to want it present on their front-end content for subscribers - so a fix there has to be.
Not (by a ling shot) all clients are using a single admin account on the site - so editing each user profile by hand is a lengthy task, and on some sites would represent an ongoing manual admin task. Not a sensible solution.
Modifying themes directly is an atrocious idea and should be strongly discouraged; most decent themes these days use the WP system to issue updates, and when one of these hits its very likely to obliterate you fix again. So you need to construct a child-theme in which to do this variation of the fix - on every site, for each theme used. Great.
So basically; by not really finishing the integration of this feature in a responsible manner (see below for justification of this assertion) the dev team have saved themselves some time, by creating a chunk of work for anyone who manages multiple sites (i.e. me and people like me). Not good.
The problem is, for some reason nobody on the WP dev team managed to ask or answer the question; "have we put the blog owner in control of when, how and if this feature is used on their blog?"
The answer is transparently "No" - and to any responsible developer releasing to a large installed user base, that would mean the feature isn't finished yet, and hence should not be released.
At the very minimum this addition should have:
had a 'use/don't use' global setting exposed in the admin GUI
for preference upgrades to existing sites should have defaulted this feature to 'Off'
Posted 2 years ago #
Hi Richard - there's a very simple reason I went in both feet first. I'll use someone else's apt words pointing at the heart of what sparked the intensity of my ire:
That was discussed, ad naseum, months and months ago.
In other words: this is a bug-feature that was browbeaten into release its current form. Deal with it. STFU already, it's a done deal. Something like that.
Since discussion "ad nauseam" among a crowd of (no pun intended) enlightened and intelligent devs didn't lead to a sensible outcome, that's why I thought a change in volume and tone might be helpful to drive the message home: do not want. Not with those default settings, not with that curious design of per-user settings.
Bottom line is: you and I both agree on the premise and nature of the problem as we see it. We both recognize the admin bar as a concept is by any means a useful idea (in essence, a UI tweak to facilitate site management, and what's wrong with that?) but sadly it was implemented horribly. Putting it into release with the current default setting (i.e. visible out there) is insensitive. Period. Again, that's the particular aspect of tactlessness that worked as a proverbial red cloth on this bull: it's done, deal with it. That's what annoyed me into gruff mode. Now, all that Monday self-quarterbacking aside, it's still troubling that it was put out the way that it was. Yet as some others already have said: it's a bug-feature here to stay, so let's suck it up.
Apparently, your fundamental (and righteously asked) question about who should really be in control of the site doesn't matter much; it's a developer-driven world, so we might as well get used to it. Even though it begs the question if there isn't a better way, a more efficient way to test developer brilliance in the cold waters of humble and quasi illiterate real-life users, before certifying it as the outcome of some election.
(Oh, and: you're 100% about putting the admin bar killer in the child theme's functions.php - I was sloppy.)
Posted 2 years ago #
nv1962: "Bottom line is: you and I both agree on the premise and nature of the problem as we see it."
Absolutely. The tone in my posts (apart from the first) is the result of considerable tongue biting and counting to 10 before posting.
Posted 2 years ago #
Well; the plugin is built. I'm going through the hoops/process to see if I can get it on the WordPress plugins hosting system.
Screenshot:
http://flic.kr/p/9kH3aU
Yep; its a pretty uninspiring looking thing.
Its available as a zip you need to install manually here:
http://db.tt/N6iwRd4
Obviously that version is supplied "as is"...
This topic has been closed to new replies.
