未加星标

Hacking WP-config

字体大小 | |
[开发(php) 所属分类 开发(php) | 发布者 店小二04 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

The wp-config.php file is an essential part of your WordPress site. It’s the bridge between the file system of your site and your database because… it contains your username and password. If that information is incorrect (or not present), you get the notorious white screen that displays: “Error establishing database connection”.

Additionally, the default wp-config.php is used to:

Define security keys, Specify the database prefix, And specify the default language for the admin area of the site.

But we can do a lot more with it as well. A whole lot more.

Here are a few of the ways you can better utilize your wp-config file via a plain text editor. All changes will reflect immediately and, thankfully, are immediately reversible.

Of note: If your site is on a WordPress-specific or managed WordPress host, you may have already noticed that your wp-config file looks very different from the default one. That’s because it can be used to extensively customize many features of your WordPress installation.

PERFORMANCE Priority Caching

Wp-config.php is one of the first things loaded visitor hits your site. So if you use a caching plugin like WP Super Cache or Fastest Cache, those plugins will enable the cache constant:

define('WP_CACHE', true);

Doing so allows the caching plugin to take over and bypass the performance-rich WordPress processes likephp and your database. If this constant is not defined or defined too late in the file, the cache will not execute and WordPress loads normally.

Memory Limitations

A very popular tweak is to use the wp-config file to increase the PHP memory allowance for your WordPress instance. If you’re running some intensive plugins like WooCommerce, WPML, or even an intensive theme like Avada, you’ll need at least 128 MB, or more likely, 256 MB.

Memory issues can create aslow admin area, a white screen incomplete loading of pages, or fatal errors. You can define the memory like this:

define( 'WP_MEMORY_LIMIT', '128M' );

Depending on your host’s set-up and limitations, there may be an upper limit for the memory allowance, which the wp-config cannot override. You can also define a memory limit for the admin area specifically:

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

For more info about memory limits and how to debug related error messages, I recommend this post by Donncha Caoimh.

Post Revisions

By default, WordPress stores revisions of your posts every time you save it, making it easy to access previous versions. But as useful as this feature is, multiple revisions can add to the weight of your database and create unnecessary bloat. This can potentially impact your site’s performance.

An easy way to make sure post revisions don’t get out of control is to set up a maximum limit on the number of saved revisions. Specified in the wp-config file, of course. The example below creates a maximum of five revisions:

define( 'WP_POST_REVISIONS', 5 );

You can also disable revisions entirely:

define( 'WP_POST_REVISIONS', false );

Pro Tip: If you’re building a site for a client, make sure you tell them you’re doing this!

Cleanup Image Edits

This is an extremely powerful tweak to keep your uploads folders in check. As you may know, when you upload an image to WordPress a variety of sizes are created based on your Media settings alongside any custom sizes specified by themes and plugins. So for any given image, you’ll receive a minimum of four versions (the original plus thumbnail, medium and large), if not more.

Now, imagine you edit that image within WordPress. You will create another four files for the new, edited version, in addition to the original set of files. Another edit leads to yet another set…. and so on. Say hello to unnecessary files.

This behavior can be modified with:

define( 'IMAGE_EDIT_OVERWRITE', true );

With this definition, WordPress will only keep the original set of files plus the most recent set of edited versions, not all edited versions. Phew! For more background on the origins of this, check out this article .

DEVELOPMENT Site URLs

WP-config provides the ability to define the WordPress and site address URLs. This tweak comes in particularly handy when migrating a site from one domain to another. It takes precedence over what is entered in Settings > General.

define('WP_HOME', 'http://www.example.com'); // no trailing slash define('WP_SITEURL', 'http://www.example.com'); // no trailing slash

This removes the need to either update the URLs in the WordPress admin area or in the database itself. Why do that? Well, a mistake in the admin screen will kick you out of the site and force you to go to the database anyway. Additionally, editing the database could be unwieldy since you have to log into and navigate the hosting control panel. So defining the URLs in wp-config can make a transition easier.

You can even make the definitions dynamic so that you can move the site without editing the file :

define('WP_HOME','http://'. $_SERVER['SERVER_NAME']); define('WP_SITEURL','http://'. $_SERVER['SERVER_NAME']);

Neither of these tweaks completely negates the need to update the database, but I would recommend using them as a temporary workaround for site migrations.

Troubleshooting

There are a few settings that can help developers to debug problems.

The first is to display errors:

define('WP_DEBUG', true);

This will actually display any errors on the front end of your website. That’s fine for a local or development site, but certainly not for a live site. In that case, you can instead log those errors to a file instead of displaying them on the front end by adding the following lines:

define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);

This creates a debug.log file in wp-content. I recommend turning off logging once you have the necessary info you need to avoid impacting performance.

Unraveling Minification

Minified scripts and styles can add a layer of complexity and obscurity when debugging. To avoid this, use the following:

define( 'SCRIPT_DEBUG', true );

Now WordPress itself will load the un-minified versions of its files instead of the .min.css and .min.js versions.

I use this mostly for debugging minification issues. like a performance plugin that provides minification and concatenation. In those cases, assets from your site are combined into one or a few files and so the individual file paths are obscured. Enabling the script_debug feature reveals those full file paths, a huge help in troubleshooting.

Jetpack Developer Mode

Jetpack is a powerful tool, but not all of its require a connection to WordPress.com . By turning on developer mode you can gain access to these features without going through the connection process. Simply add the following to enable Jetpacks’ developer mode:

define ( 'JETPACK_DEV_DEBUG', true); Plugin API Keys

Some premium plugins allow you to define your API key in the wp-config file for convenience. For example:

Soliloquy:

define('SOLILOQUY_LICENSE_KEY','your_license_key');

Gravity Forms:

define( 'GF_LICENSE_KEY

本文开发(php)相关术语:php代码审计工具 php开发工程师 移动开发者大会 移动互联网开发 web开发工程师 软件开发流程 软件开发工程师

主题: PHPWordRYEDI
分页:12
转载请注明
本文标题:Hacking WP-config
本站链接:http://www.codesec.net/view/530342.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 开发(php) | 评论(0) | 阅读(32)