Codex tools: Log in
Contents
|
My username is derived from one of my old businesses, Butler Creek Works.
I'm new to WordPress and server side scripts, but fairly experienced in client side programming, and I pick up computer skills fairly quickly, so I probably know more than most users at this point. I should probably learn more about formatting wiki pages next.
When searching for information in the Codex, I come on information that appears outdated, I hope to contribute to updating things like this when ever my knowledge is adequate. I also see minor errors, like spelling, or grammar, which should be corrected for the Codex to be more professional and authoritative.
One of my peeves about the Codex in it's recent current state is there is little mention of Child Themes in many of the articles about customizing WordPress. When I first started my own site, I made a bunch of changes to the twentyeleven theme before I stumbled onto the Child Theme page. Realizing the superiority of this method, I had to go back and diff out and transfer all my changes to my new Child Theme, then finally restoring the original twentyeleven from backup.
9 Nov '11 - I've gone back and salted a bunch of references to Child Themes in the Codex, so hopefully no one makes my mistake again.
My browser bookmarks are cluttered enough, so I keep WP related links here that I find useful for reference.
I use this area as my personal sandbox to draft content I plan to contribute to the Codex that is a bit too involved to just edit on the fly in the Codex page's edit box.
There are a few articles on the 'net on setting this up, but there's no obvious mention in the Codex about how important this is. We need an overview of the steps with links to the various articles. May need to tie up some loose ends, like accessing the local development server over a LAN, since 127.0.0.1 will not work. It's not even clear where to put references to this new page so that it is seen, but not starting to look a bit like link spam, as there's no obvious entry point for new developers.
Coming Soon
The 'backs sections are vague on how to actually make trackbacks work and the fact that pingbacks are completely automatic.
This Codex sub-section should perhaps be retitled 'Using Pingbacks and Trackbacks'?
To enable trackbacks and pingbacks, in the Disscussion Settings of your Administration Panels, select these items under 'Default article settings':
Attempt to notify any blogs linked to from the article.
Allow link notifications from other blogs (pingbacks and trackbacks.)
Selecting one option and not the other would not be very neighborly ;◦)
Once enabled, trackbacks and pingbacks from other sites will appear in your Administration Panels just like other comments, but on your post pages, they will appear according to your theme's design.
Once enabled, pingbacks are sent automatically when you publish your post, you don't have to do anything. To send trackbacks, you will need to find the trackback URL somewhere on the post page you are linking to. If you can't find one, try to determine if the site supports pingbacks. If it does, you should not send trackbacks as well. Copy/paste the trackback URL into the Send Trackbacks field on your Add New Post screen. If you don't see this field, go to the screen options and select the Send Trackbacks option. Note that selecting this does not send trackbacks, it only displays the field called Send Trackbacks. When you publish your post, trackbacks will be sent to the URLs you pasted into the field. This field will also show the status of trackbacks and pingbacks on your Edit Post screen.
Things are rather vague on Configure Error Log in Editing wp-config.php on how the PHP directives and WordPress error constants do or do not interact. There's also a security issue with the debug.log located in a publicly accessible directory.
Retitle sub section as above. Under current Configure Error Log at top add:
Configuring error logging can be a bit tricky. First of all, default PHP error log and display settings are set in the php.ini file, which you may or may not have access to. If you do, they should be set to the desired settings for live PHP pages served to the public. It's strongly recommended that no error messages are displayed to the public and instead routed to an error log. Further more, error logs should not be located in the publicly accessible portion of your server. Sample recommended php.ini error settings:
error_reporting = 4339 display_errors = Off display_startup_errors = Off log_errors = On error_log = /home/example.com/logs/php_error.log log_errors_max_len = 1024 ignore_repeated_errors = On ignore_repeated_source = Off html_errors = Off
Obviously, you will want different settings for your development environment. If your staging copy is on the same server, or you don't have access to php.ini, you will need to override the default settings at run time. It's a matter of personal preference whether you prefer errors to go to a log file, or you prefer to be notified immediately of any error, or perhaps both. Here's an example that reports errors immediately that you could insert into your wp-config.php file:
@ini_set('log_errors','Off');
@ini_set('display_errors','On');
@ini_set('error_reporting', E_ALL );
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', true);
the start of current entry
Because wp-config.php is loaded for every page... blah blah
... and at end add:
Confusing the issue is that WordPress has 3 constants that look like they could do the same thing. First off, remember that if WP_DEBUG is false, it and the other two WordPress DEBUG constants do not do anything. The PHP directives, whatever they are, will prevail. Second, even if WP_DEBUG is true, the other constants only do something if they too are set to true. If they are set to false, the PHP directives remain unchanged. For example, if your php.ini file has the directive display_errors = On, but you have the statement define('WP_DEBUG_DISPLAY', false); in your wp-config.php file, errors will still be displayed on screen even though you tried to prevent it by setting WP_DEBUG_DISPLAY to false because that is the php configured behavior. This is why it's very important to set the PHP directives to what you need in case any of the related WP constants are set to false. To be safe, explicitly set/define both types. More detailed descriptions of the WP constants is available at Debugging in WordPress.
For your public, production WordPress installation, you might consider placing the following in your wp-config.php file, even though it's mostly redundant:
@ini_set('log_errors','On');
@ini_set('display_errors','Off');
@ini_set('error_reporting', 4339 ); //only log errors you will want to know about
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);
The default debug log file is /wp-content/debug.log. Placing error logs in publicly accessible locations is a security risk. Ideally, your log files should be placed above you site's public root directory. If you can't do this, at the very least, set the log file permissions to 600 and add this entry to the .htaccess file in the root directory of your WP installation:
<Files debug.log> Order allow,deny Deny from all </Files>
This prevents anyone from accessing the file via HTTP. You can always view the log file by retrieving it from your server via FTP.
The whole customizing read more section is largely oriented to someone creating their own template. It's less useful to child theme users as the suggested changes to the parent theme would need to be reapplied any time the theme is updated. A different strategy is needed for child theme users, particularly if the parent is twentyeleven. It will require a hook for both the_content and the _excerpt to address all possible combinations of user input and theme post styles. This page needs significant reorganization, or perhaps instead, a separate page oriented to child theme users.
Will add sub section to this subsection of Customizing the Read More page. When using child theme of twentyeleven template, can't set the more link with excerpts with just the shown code. Need to remove the parent theme's filters trying to customize the same thing. But we can't remove the filters directly because the parent's function.php has not been loaded yet. Need to hook the action 'after_setup_theme' and remove filters at that time.
If you are using a Child Theme, the above code will not work without modification if the parent theme has it's own filters setting it's own "more link" text. You will need to use the remove_filter() function to remove the parent's filters for yours to work. The problem is your functions.php file is loaded before the parent's functions.php, so at the time of your file's execution, there is no filter to remove yet, and your remove_filter() code will fail without warning.
The key is to put your remove_filter() code in a function that executes from an action hook that triggers after the parent theme is loaded. The following code is an example of the additional code needed to get the above code to work from a child theme of the parent theme twentyeleven. You will need to examine your actual parent theme's code for the correct parameters in the remove_filter() code, they must exactly match the add_filter() parameters used by the parent.
function child_theme_setup() {
// override parent theme's 'more' text for excerpts
remove_filter( 'excerpt_more', 'twentyeleven_auto_excerpt_more' );
remove_filter( 'get_the_excerpt', 'twentyeleven_custom_excerpt_more' );
}
add_action( 'after_setup_theme', 'child_theme_setup' );
I looked through the code WordPress uses to validate e-mail addresses and saw that all it does is check that it's properly formed and uses only permitted characters. A way to do a more stringent behind the scenes e-mail validation would be a useful function, but I couldn't find anything in the Codex. After doing some research, I wrote some code to check for the existence of a mail exchanger within the address' domain. This question will go on the FAQ Working with Wordpress page, under spam and comments.
WordPress checks to see that the address provided is a properly formed address. WordPress does nothing to determine if the address would actually work. There are other measures administrators can do to verify if an e-mail address actually works.
Most people have experienced the challenge and reply e-mail exchange where the commenter is sent a message within which is a link they must follow to validate that their e-mail address actually works. There are a few Plugins that provide this sort of validation. While this method provides accurate validation, it takes away the immediacy of posting a timely comment, and can further frustrate users if there are delays in message transmission.
A behind the scenes method that requires no action by the commenter has a few benefits. One way to get an indication of the validity of an e-mail address is to use the PHP function checkdnsrr() to check if a domain record exists showing a mail exchanger on that domain. This method is less than 100% reliable, as it does nothing to verify if there is a valid mailbox within that domain.
Extending the WordPress e-mail check function to include this verification is fairly simple. You could create a very basic Plugin and insert the following code:
// extend e-mail check to include checking DNS for a valid domain with mail exchanger
// returns false if check fails
function check_email_domain($valid, $email, $type) {
if ( !$type && $valid ) {
// address has passed all other checks, let's do ours
list($userName, $mailDomain) = explode("@", $email); //extract domain
if (checkdnsrr($mailDomain, "MX")) {
// this is a valid email domain, return the e-mail address
$pass = $email;
} else {
// this email domain doesn't exist, return false
$pass = false;
}
// else $type has value or $valid is false, address has failed a previous test,
// just pass it on
} else {
$pass = $valid;
}
return $pass;
}
add_filter('is_email', 'check_email_domain', 10, 3);
Creating plugins can be very easy, the above code actually has most of the work done for you.
A more thorough behind the scenes method is to query a domain's SMTP server to verify if the username is associated with a valid mailbox. Even this is not 100% accurate, as some domains will return a valid mailbox answer to any query whether the mailbox really exists or not. Furthermore, if you run this sort of query often enough, it will get your domain blacklisted for 'namespace mining behavior.' Another way !@#* spammers have ruined things for all of us!
I drafted a major update to the following very outdated section from FAQ Working with WordPress. I spent a fair bit of time trying to get the code provided in the old version to work before I realized there was no need to do anything at all. This was my working copy to be sure all the formatting and links worked. I suppose I could delete it now that I've updated the actual page.
Moved to relevant Codex page.
Warning Box for FAQs that direct users to alter core files. I didn't know where to find a text box example, so used a table cell, which does not work too well because there is no padding. There's probably a way to fix that, but I'm too tired to figure it out.
Well, DUH! I didn't know we can use inline CSS here! I know how to do that!
Superceded by CSS version
Moved to relevant Codex pages
