Custom Login Page Link

This is the link and link title on the login page.

along with some code snippets on how to handle this:

http://premium.wpmudev.org/forums/topic/remove-wp-about-menu-from-toolbar#post-161711

There are a few options. First the manual edits:
Open the file:
/wp-includes/class-wp-admin-bar.php
And around line 456:

456

add_action( 'admin_bar_menu', 'wp_admin_bar_wp_menu', 10 );

Comment it out or just remove the whole line. Now the WP links part is all gone!
But….. But……… If you wanted to edit those links to customise yourself, you could just go open up the file:
/wp-includes/admin-bar.php
You’ll see it all near the top, here is a short snippet:

if ( is_user_logged_in() ) {
// Add "About WordPress" link	 $wp_admin_bar->add_menu( array('parent' => 'wp-logo', 'id' => 'about',	 'title'  => __('About WordPress'),	 'href'   => admin_url('about.php'),	 ) );
}

You will note much of the same on there.
The logo is part of a sprite which can be found here:

/wp-includes/images/admin-bar-sprite.png

Both of these options mean updating the code every time you upgrade your WP install.
And now the final option, which is the easiest, but its yet another plugin………

Remove WordPress Admin Bar Links

Enjoy, its free!!

Well if you don’t see the WordPress Admin Bar on the front end then it is likely your theme is missing two functions:

<?php wp_head(); ?>

<?php wp_footer(); ?>

The CSS for the admin bar is loaded through the wp_head() function and the navigation is pulled through the wp_footer() function.

wp_footer() should be added just before your HTML closing body tag and is used by plugins usually for such things as add Java.

<?php wp_footer(); ?>
</body>
</html>

wp_header() should be called just before the closing your HTML head code and is used for things like CSS, Meta data and so on. If you use script in your head and have java there, that may need to be written after the wp_header() function is called.

<?php wp_head(); ?>
</head>

Remove Default WordPress Bar

Unzip and upload the file “remove-wpbar.php” to your “mu-plugins” folder to have it activated for all websites. Or upload the file to your normal plugins folder and “Network Activate.

First of all if you are runing a vanilla install of WordPress you will have no doubt noticed that when system e-mails are sent out that the address is usually wordpress@yourdomain.com and of course you could most likely find a plugin to combat this but is a another plugin bloating your install really what you need?

So, where can you change this in the core code?

/wp-include/pluggable.php

Around line 391:

391

$from_email = 'wordpress@' . $sitename;

Around line 1057:

1057

$wp_email = 'wordpress@' . preg_replace('#^www\.#', '', strtolower($_SERVER['SERVER_NAME']));

So that is the default out of the way!

Now you are running BuddyPress and you notice that your “Contact Form 7″ or Supporter form is sending out e-mails with a sent address from noreply@yourdomain.com, of course this is damn annoying, it makes it more time consuming when you make replies, often you send an e-mail to yours noreply address and then get angry clients asking why you haven’t contacted them back, or if you use a support desk so you can’t just reply to that ticket. Its most annoying when all you need to do is reply yes or no and especially so when using the supporter form for your clients.

So the problem! It is actually buddypress causing the issue here. At least in 1.2.8 (Not checked other versions) You see it ads filters to the default WP_Mail function forcing its own headers. What you need to do is remove those filters and everything will be back working as it should.

Contact Form 7, Add the following:

remove_filter('wp_mail_from', 'bp_core_email_from_address_filter' );
remove_filter('wp_mail_from_name', 'bp_core_email_from_name_filter');

In the compose_and_send_mail() function around line 693:

693
694
695
696
697
698

	function compose_and_send_mail( $mail_template ) {
 
		remove_filter('wp_mail_from', 'bp_core_email_from_address_filter' );
		remove_filter('wp_mail_from_name', 'bp_core_email_from_name_filter');
 
		$regex = '/\[\s*([a-zA-Z_][0-9a-zA-Z:._-]*)\s*\]/';

Now it will use what ever you stipulate in the admin area of Contact 7 which is usually the e-mail address for the person contacting you!

And the WPMUDEV Supporter plugin, open the following:

/wp-content/mu-plugins/supporter-premium-support.php

Add it to the supporter_support_page() function which is approx. line 94 it should then look like this:

94
95
96
97
98

function supporter_support_page() {
  global $current_user;
 
	remove_filter('wp_mail_from', 'bp_core_email_from_address_filter' );
	remove_filter('wp_mail_from_name', 'bp_core_email_from_name_filter');

You could if you wished wrap it up in some conditional statements to check for BuddPress first, but for me it is always installed, at least for now!

If you are not using BuddyPress or you still have this issue after removing the filters then chances are there is another plugin or even theme which is forcing its use of the wp_mail() function.

Note: One thing to remember is that making changes directly to the main files of WP, a plugin or theme means that when you come to upgrade you will need to remember to make those changes again! I prefer this over bloating an install with plugin after plugin.

Anyway, so if you’ve already overwritten your files with the new upgrade and your presented with a white screen or you having bodged upgrades then chances are its a module. First of all make sure you have a back up of your installation (which you should have from before the white screen and upgrade issues), reinstate your database to the back up (the bodged upgrade could have altered the tables). Log into your PHPMyAdmin or equivalent and then run this MySQL code.

Update table_modules SET isactive = '0' WHERE isactive = '1'

Make sure that this “table_modules” is changed to your table, so if its “mysite_modules” then put that other wise this won’t work.

MySQL Disable ICMS And Xoops Modules

Hit the go button and now all your active modules will be deactivated, now try your website and upgrade, hopefully this might have solved the issue for you. If it does, then only activate your modules one by one to find out which one was the trouble causer.

Why should I change the generator of my WordPress install?

WordPress, your themes and many plugins like to display the version number of your installation, this is a great way to let a potential hacker or cracker know if your using an insecure and buggy version and even though whilst your installing WordPress it may seem secure, at a later date a vulnerability may be found. Personally because of this I don’t like to display those details, Google maybe your friend along with other search engines, but remember they don’t only help you find sites.

Anyway, I digress again!

Open /wp-includes/general-template.php

Around line 2202 you will find a PHP switch with the following code:

2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224

switch ( $type ) {
	case 'html':
		$gen = '<meta name="generator" content="WordPress ' . get_bloginfo( 'version' ) . '">';
		break;
	case 'xhtml':
		$gen = '<meta name="generator" content="WordPress ' . get_bloginfo( 'version' ) . '" />';
		break;
	case 'atom':
		$gen = '<generator uri="http://wordpress.org/" version="' . get_bloginfo_rss( 'version' ) . '">WordPress</generator>';
		break;
	case 'rss2':
		$gen = '<generator>http://wordpress.org/?v=' . get_bloginfo_rss( 'version' ) . '</generator>';
		break;
	case 'rdf':
		$gen = '<admin:generatorAgent rdf:resource="http://wordpress.org/?v=' . get_bloginfo_rss( 'version' ) . '" />';
		break;
	case 'comment':
		$gen = '<!-- generator="WordPress/' . get_bloginfo( 'version' ) . '" -->';
		break;
	case 'export':
		$gen = '<!-- generator="WordPress/' . get_bloginfo_rss('version') . '" created="'. date('Y-m-d H:i') . '"-->';
		break;
	}

Basically a switch tests a case and if it matches it executes the cases code, so if your on a HTML page you will execute the part located in the case ‘html’:

2202
2203
2204

case 'html':
	$gen = '<meta name="generator" content="WordPress ' . get_bloginfo( 'version' ) . '">';
	break;

You don’t really need to understand that to be honest, just change the relevant parts, your end result should look like the following:

2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224

switch ( $type ) {
	case 'html':
		$gen = '<meta name="generator" content="SJBNetwork">';
		break;
	case 'xhtml':
		$gen = '<meta name="generator" content="SJBNetwork" />';
		break;
	case 'atom':
		$gen = '<generator uri="http://sjbowers.net/" version="na">SJBNetwork</generator>';
		break;
	case 'rss2':
		$gen = '<generator>http://sjbowers.net</generator>';
		break;
	case 'rdf':
		$gen = '<admin:generatorAgent rdf:resource="http://sjbowers.net" />';
		break;
	case 'comment':
		$gen = '<!-- generator="SJBNetwork" -->';
		break;
	case 'export':
		$gen = '<!-- generator="SJBNetwork" created="'. date('Y-m-d H:i') . '"-->';
		break;
	}

Now if your running a WordPress multisite you won’t have to add a new function to every theme on your install, but keep in mind that some themes do add the generator meta tags themselves.

Remember though that when you update your WordPress installation that will need to make this change again.

If you do the above, you don’t need to do the next part to change the displayed generator in your theme.

If you are looking for the other option of adding a php function to your theme then open your themes folder, locate functions.php and add:

2202

remove_action('wp_head', 'wp_generator');

Make sure this is encased in php tags.

You will have seen many sites and people in forums say edit your php.ini, but sometimes it doesn’t appear to work, well there are a couple things to remember:

• WordPress Upload Limit – If in the admin you have a site set to only have a 10MB, then naturally you won’t be able to upload more than 10MB, so you need to change that.
• In your Multisites admin you need to up the max upload size http://yoursite.com/wp-admin/ms-options.php

WordPress 3.0 Options Admin For Upload Size.

• You might set a default upload limit of say 10MB, but some sites you give more to, perhaps they are your own sites, or your client pays you for more space. Simply go to http://yoursite.com/wp-admin/ms-sites.php edit the site you want to up the limit on, you will find “Site Upload Space Quota”, change that to something higher.

Changing a single sites upload limit

Now thats done and your happy with the sizes you want, you will need to create a php.ini file and pop it into your /public_html/ (If you own the server you could change the sites in your main php.ini file), att the follow to this file:

memory_limit = 100M
 
post_max_size = 100M
 
upload_max_filesize = 100M
 
max_execution_time = 360
 
max_input_time = 120

I’ve changed the execution because larger files naturally take longer to upload and you don’t want things timing out, if they do then up it a little more. We have audio and video files uploaded. Don’t forget to check those changes have taken affect with PHPInfo.

Create a php file, call it whatever you like, perhaps just phpinfo.php, then add the following, save it and upload it:

phpinfo();

Load the file in your browser to see your php configuration.

The next part with running WordPress 3.0 Multisite is that you want these changes to be site wide and not just directory specific. Open your .htaccess and add the following line:

suPHP_ConfigPath /home/yoursite/public_html

Change the part /yoursite/ to what your physcial site location is. Normally with cpanel it would be your username (not e-mail address, but cPanel username). Check your upload forms now, they should all be showing the right upload size.

Upload Form with 100MB Limit

This one is a simple one, the CSS class for this element is “form-allowed-tags”, and all you need to do is set it to display none.

Open your themes CSS file, most likely style.css, it will be in the folder of your websites theme.

.form-allowed-tags { display:none; }

There is a chance that your themes CSS file already has this class, you could check. It’s doubtful but possible that this could have been declared elsewhere, if thats the case you should hunt it down and fix it there but you could also try:

.form-allowed-tags {display:none !important;}

There are a ton of plugins which will help you customise certain aspects of your installation but very little in terms of the contextual menu which is a drop down in the administration area.

Note:- If you are aiming to have many websites in your installation then you really need to consider going streamline, to many plugins will only cause you headaches later on and its the type of headaches where your host could pull your services, shut you down and even if your on dedicated servers it could bring those to their knees, even a powerful one. WordPress + plugins = Resource intensive hog, not to menion the potential for more security issues where crackers will gain back doors in to destroy your website which actually happened to a good friend of mine recently.

Anyway, the point of this note which was suppose to be much shorter is if you can avoid a plugin, then AVOID a plugin it will put less strain on php being processed (less code is better) with Apache and your database. Hardcode your changes where possible.

So, blah, blah, blah, I waffle on sometimes I know.

Open /wp-admin/includes/template.php

Around line 3643 you will see this code:

3643

<div id="contextual-help-link-wrap" class="hide-if-no-js screen-meta-toggle"><a id="contextual-help-link" class="show-settings" href="#contextual-help"></a></div>

That code right there is the html use to display this menu, removing that will remove the click-able div, hence giving you users nothing to click on at all.

Things to consider:

1. Upgrading your install will potentially revert this change.
2. Users will no longer have access to the drop down help which some plugins and themes may refer to.
3. The actual code used in Java script and such still exists, this only really removes the cosmetic part.

I love WP but when you offer a service to a client you may want to be their first point of contact especially where they may not be so experienced, following instructions which can sometimes be a little more technical could end up causing more issues for them. This is of course my opinion, I’m sure many won’t agree.