A working index.php can look like this:
#+BEGIN_EXAMPLE
The parent's function has to be written like this:
if ( ! function_exists( 'storefront_footer_widgets' ) ) {
/* some content here */
}
So if your child theme's function.php has the function
function storefront_footer_widgets () {
/* some code here */
}
Then your child theme's function will overwrite the parent's function. Cool eh? 2085 Puget Drive West Lafayette, * wordpress template hierarchy
When wordpress views a specific webpage, it selects in page that is the highest in the hierarchy. wordpress wrote "20 14", "20 23", "20 12", and "20 10", for developers to study! I can learn how wordpress builds themes by studying those themes.
#+BEGIN_SRC #+END_SRC
Template tags are like the titles of the temp workers at the dam. There's a supervisor (Jim), concrete pourer (Rick), structural specialist (Don), etc. During construction of the dam, you refer to these people as supervisor or boss, but when it's time to get execute processing of payment (executing the php code), then you have to expand the supervisor's name to "John Fullname".
A post is content that a user inserts into wordpress.
#+BEGIN_SRC /* make the woocommerce_breadcrumb do nothing */ function woocommerce_breadcrumb () {
An action is like drinking dirty water. You do something: ie drink dirty water. Filters change things.
A filter hook lets you use a php function to do something to data before it is displayed. ie:
$title = apply_filters('wp_title', $title, $sep, $seplocation);
This above is a code snippet from wordpress core that lets you do something to the title before it is rendered on the page, like truncating it if the title is too long, etc.
actions let a developer modify or add to wordpress functionality filters let a developer alter content before the user sees it https://members.nearlyfreespeech.net/jbranso/support/wordpress_adv
members.nearlyfreespeech.net Advanced WordPress Configuration - NearlyFreeSpeech.NET Member Interface
Note: Everything on this page assumes that you set up WordPress in accordance with our installation guide and that you are running WordPress on at least Apache 2.4 and PHP 5.4. If any of these assumptions are not correct, the instructions below may fail horribly. Recommended Plugins Spam filtering
We recommend Akismet, which comes standard with WordPress. To activate it with WP-CLI:
wp plugin activate akismet
Additional configuration will be required from the WordPress dashboard "Plugins" section once Akismet is activated; visit that section and you should see a prompt to activate your Akismet account. Stopping Login Attacks
If you encounter frequent problems with attackers using bulk attempts to attempt to hack their way into your WordPress blog, you may want to consider relocating the login script. This can be accomplished using the sf-move-login plugin.
Before continuing, make sure you are already logged in to the admin interface for your blog.
Install the plugin like any other:
wp plugin install sf-move-login wp plugin activate sf-move-login
Once this is done, there are still two additional steps to make this work.
First, you will need to set the new login link. To do this, go to the "Settings" entry on the WordPress admin panel's sidebar, and then select the "Move Login" entry under that. On the "Move Login" Settings page, enter the new login path (e.g. secretdoor). You can also change the URLs of other common actions from here, but login is by far the most commonly attacked. Click the "Save Changes" button to save your entry.
Next, you must edit your .htaccess file. After you click "Save Changes" the page will reload. Right below that button, the page will list the code you need. Cut and paste the contents of the textbox into your .htaccess file. (Make sure to do this after you save any changes.)
After completing all the steps, this will have the effect of changing your blog's login page from /wp-login.php to /secretdoor. You can (and should) customize secretdoor to whatever you want to use. You may also wish to edit your theme to remove references to the login page, but that is optional.
We recommend that you configure and test this with two different browsers open (e.g. Chrome and Firefox), one that is logged in to the WordPress Dashboard that you can use for the configuration, and one that is not that you can use for testing.
If something doesn't go according to plan and you wind up locked out of your blog, you can add this line to your wp-config.php file to temporarily disable the plugin so you can get logged in:
define( 'SFML_ALLOW_LOGIN_ACCESS', true ); # Do NOT use unless locked out.
Make sure not to add this blindly or leave it in there if needed, as it will defeat the purpose of the plugin. Blocking Pingbacks
Unfortunately, the "pingback" feature of WordPress can be used to attack other sites. And when attackers use it to attack other sites, it will generally block any legitimate visitors from your site as well. To help keep the Internet (and your own site) safe, you should strongly consider blocking pingbacks.
XML-RPC is used by remote posting tools like mobile apps or third-party sites that post to your blog. If you don't use XML-RPC at all, and most people don't, you can change the permissions of xmlrpc.php to 600 after each update and completely immunize your site from this issue: it will stop your site from being used in attacks, and will prevent would-be attackers from wasting your resources. (Incidentally, this is what we will do if we see your site participating in this type of attack.)
If you do use XML-RPC, you can use a simple plugin that disables the pingback feature but leaves the other functions intact:
wp plugin install disable-xml-rpc-pingback wp plugin activate disable-xml-rpc-pingback
This plugin doesn't need any configuration. It isn't 100% effective like disabling XML-RPC entirely, but it's easy, minimally invasive, and still very effective in greatly reducing resources wasted by would-be attackers. General security
Try Wordfence. To install and activate it with WP-CLI:
wp plugin install wordfence wp plugin activate wordfence
Additional configuration will be required from the dashboard "Plugins" section once it is activated; visit that section and you should see a prompt to start a tour of the plugin. In the left-hand navigation column, it also adds its own "Wordfence" section from which you can access the tour, tools and configuration options.
In most cases, the defaults are good, but you should check the following options:
Make sure the options for firewall, login security, Live Traffic View, and automatic scheduled scans are enabled. Disable the option to automatically update Wordfence; it won't work. When you get an email that Wordfence (or WordPress itself, or another theme or plugin) needs an update, just pop in and update it with WP-CLI.
Depending on your personal situation and desires, many of the other options can be safely tweaked as well. Content caching
Content caching can speed up your site and is highly recommended for WordPress site that experiences even occasional bursts of activity. We have tested and recommend Hyper Cache.
First, in the root directory of your WordPress installation (home/public for these instructions), do:
chmod 775 wp-content/ chgrp web wp-content/
This plugin also requires switching to "pretty" permalinks; visit Settings > Permalinks in the WordPress dashboard. First choose your format (we like "day and name"), save the change, and then you'll need to add a few lines to an .htaccess file in your blog's root directory. Those lines will be shown at the bottom of the permalinks configuration page; be sure to select all of them before pasting them into your .htaccess file. Once you've set this up, in WP-CLI, do:
wp plugin install hyper-cache wp plugin activate hyper-cache
Then add the following line to your wp-config.php file (at the beginning just under the
define( 'WP_CACHE', true );
Then at the command line, in the WordPress base directory do:
mkdir -p wp-content/cache chgrp web wp-content/cache chmod 775 wp-content/cache mkdir -p wp-content/cache/hyper-cache chgrp web wp-content/cache/hyper-cache chgrp web wp-content/plugins/hyper-cache/*.php
(The directories might have been created for you already, but if so they'll still need permissions and ownership set.)
After this, you can tweak settings for Hyper Cache from the WordPress dashboard at Settings > Hyper Cache. Be sure to visit their site for more information about how to verify that Hyper Cache is working, and how to customize it. Receiving update notifications
It's a good idea to set up a way to find out when your WordPress core, plugins and themes have updates available. Here are a few good options:
WP Updates Notifier: This plugin provides email-based notifications that include detailed information about the update and its expected compatibility with your version of WordPress. Pushover Notifications for WordPress: This plugin can send basic notifications to your iOS or Android device. It also requires the purchase of the corresponding Pushover app (iOS, Android). You can also subscribe to the WordPress announcement mailing list for information about new releases of the WordPress core and other news.
Securing your WordPress installation PHP Script Access Limitation
In your wp-content directory, you might want to consider adding the following lines to an .htaccess file to deny access to all .php scripts. This might break a few plugins or themes that use requests that bypass the regular WordPress system, but it will also break most hacking attempts, and should be included in any directory that contains uploaded or cached content. You can paste this (including the last line break) at the command line:
cat >>.htaccess <
Require all denied
NFSNRULES
To reverse this restriction for a subdirectory if needed, switch to that subdirectory and enter:
cat >>.htaccess <
Require all granted
NFSNRULES
Using HTTPS (SSL/TLS)
For WordPress 4.0 and later, no special plugin is required. To configure HTTPS for a WordPress 4.0 or later blog, follow these instructions:
First, be sure that you've set up and enabled SSL for your site, and that it's working. Add the following line to your wp-config.php file:
if ( $_SERVER[ 'HTTP_X_FORWARDED_PROTO' ] == 'https' ) $_SERVER[ 'HTTPS' ] = 'on';
In your WordPress dashboard, under Settings > General, update your "WordPress Address (URL)" and "Site Address (URL)" from "http" to "https".
For versions of WordPress prior to 4.0, to allow your WordPress site to be accessed via https, follow these steps:
First, be sure that you've set up and enabled SSL for your site, and that it's working. Install and activate Wordpress HTTPS. From WP-CLI: wp plugin install wordpress-https wp plugin activate wordpress-https Read the Wordpress HTTPS Installation Guide. In your WordPress dashboard, under Settings > General, update your "WordPress Address (URL)" and "Site Address (URL)" from "http" to "https". (Optional) After everything above is complete and working, you can require that absolutely everything on your site be accessed only via HTTPS by editing the .htaccess file at the root of your site (/home/public) to add these two lines just below "RewriteEngine On:"
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L]
Other optimization considerations Fix wp-cron!
WordPress includes the ability to set posts to appear in the future, and has a couple of other features that are time-sensitive. To implement this functionality, a default WordPress install will call a script called wp-cron.php every time it is accessed.
This behavior causes all sorts of problems, especially on busy sites. Getting called on every hit when there's almost always nothing to do is already wasteful (and "wasteful" on a service like ours that bills for resources is a code word for "unnecessarily expensive"), but the real problem comes when things get out of hand. This program has a history of locking problems, so when a site gets busy it can go crazy and wind up running dozens of times at once trying to figure out if it should be running at all (and the answer is almost always "no"). Say goodbye to your blog performance!
Fixing this issue takes two easy steps.
Simply add this text to your wp-config.php file:
define( 'DISABLE_WP_CRON', true );
Go to the site info panel and add an hourly scheduled task for your site to run wp-cron:
Tag wpcron URL or Shell Command http://example.nfshost.com/wp-cron.php?doing_wp_cron User me (not used with URLs) Hour Day of Week * Date
(Replace example.nfshost.com with your site's actual name and adjust the URL as necessary if you didn't install WordPress directly in the public directory.) You don't need to use curl or wget; a scheduled task that has a URL as its command will automatically be treated as a web request.
This approach has the additional benefit that if something weird happens while WordPress is doing its thing internally, you'll be much more likely to be get notified about it in an email message. With the default setup, those error messages may disappear into the void, never to be seen again. Preventing robots.txt and favicon.ico 404 errors
Requests for these two files can generate many 404 errors if the files don't exist. The way WordPress handles 404 errors is very inefficient, and can result in unnecessary strain on high-traffic sites if either of these files do not exist. You can create these files according to your preferences, but if you don't need them and just want to avoid the performance penalty and resource cost of having requests for them return 404 errors, it's well worth creating two empty files via ssh command line in the root directory of your site:
Get a post by a post ID
headturningfitness.com/wp-json/wp/v2/posts/ https://premium.wpmudev.org/blog/35-resources-for-kick-ass-wordpress-developers/?wpcv=b&utm_expid=3606929-93.spVh-aR3SwGklKzL4HJQQg.1&utm_referrer=https%3A%2F%2Fduckduckgo.com%2F https://codex.wordpress.org/Theme_Development
Wordpress can update itself if the user running the webserver ownes those files.
This script is obviously a php script. Put this inside your functions.php file. #+BEGIN_SRC js function adding_loading_css () { wp_register_style ('my_loading_css', '/wp-content/themes/author-landing-page-child/css/my-loading.css', '1.1'); wp_enqueue_style ('my_loading_css'); } add_action ('wp_enqueue_scripts', 'adding_loading_css'); #+END_SRC