內容簡介
Angry Creative Inspector （簡稱 Angry Inspector）可以評估、監控並尋找您的 WordPress 安裝中可能存在的問題。特別推薦給需要持續監控其網站健康情況的 WordPress 安裝維護人員。如果您使用 WP-CLI，那麼您甚至可以修復 WordPress 中出現的問題。請繼續閱讀以了解更多。
此插件有兩種類型的檢查程序：一種是每隔 24 小時運行一次的定期檢查程序，另一種是由 WordPress 觸發的挂鈎或使用者操作激活的檢查。目前，以下定期運行的檢查程序已經內建支援：
- 檔案權限檢查- 您是否在所有文件上執行了 chmod 777？
- Git 修改檢查- 是否使用 Git 版本控制 WordPress？如果是，我們會記錄未提交的文件更改。
- 資料庫排序檢查- 您的資料表是否擁有適當的字元集和排序？
- 網站可見性檢查- 您的網站是否遮蔽了搜索引擎？
然後還有以下 WordPress 觸發的挂鈎或使用者操作激活的程序：
- 外掛啟用/停用- 誰停用或啟用了該外掛？
- 使用者註冊- 記錄所有使用者註冊資訊。
- 使用者資料修改- 記錄所有使用者資料的更新，包括密碼更改。
- 使用者權限修改- 誰升級或降級了該使用者的權限？
- 網站註冊- 誰在你的網站網路中創建了該網站？
- 網站啟用/停用- 誰停用或啟用了網站網路中的該網站？
- JavaScript 錯誤記錄- 監控 JavaScript 的錯誤，甚至是出現在您訪客瀏覽器中的錯誤。
需要一些配置才能充分利用文件權限和網站可見性程序，請參閱安裝說明。
進行檢查和檢查記錄檢視：
使用管理員帳戶登入 WordPress 網站，然後在 WP 管理面板下的「設定/AC Inspector」菜單下找到 Angry Inspector 頁面。您可以在此處查看檢查記錄，並通過點擊「立即檢查」按鈕手動觸發預定的檢查程序。此外，請注意「檢查程序」和「操作程序」標籤，您可以在其中更改每個程序的記錄級別。將記錄級別設置為「忽略」即可完全禁用該程序。
使用 WP-CLI 進行檢查和修復：
首先確保您已安裝 WP-CLI，有關指示請參閱 http://wp-cli.org。然後將命令行殼層轉到 WordPress 安裝目錄，並發出以下命令：
wp angry-inspector inspect
您也可以像這樣調用特定的檢查程序（使用小寫的類或函數名，不帶「ACI_Routine_」前綴，並使用破折號替換底線）：
wp angry-inspector inspect file-permissions
如果 WP-CLI 檢查期間有任何提示，則該檢查器將尋找可能的修復方法並提示您是否要進行修復。如果有一個修復方法，您可以跳過檢查並直接進行修復。請按如下方式進行：
wp angry-inspector repair
要為特定檢查程序調用修復方法，請執行以下命令：
wp angry-inspector repair site-visibility
請注意，如果要使用類似於文件權限的修復方法，您需要以超級用戶身份運行命令。
外掛標籤
開發者團隊
📦 歷史版本下載
原文外掛簡介
The Angry Creative Inspector, or Angry Inspector for short, will weigh, measure and find possible issues with your WordPress installation. This plugin is especially recommended to maintainers of WordPress installations that needs to continously monitor the health of their sites. Got WP-CLI? Then you may even be able to repair what’s wrong with your WordPress. Read on to learn more.
The inspector has two basic types of inspection routines; regularly repeating inspections run once every 24 hours and inspections triggered by a WordPress hook or user action. Currently, the following regularly running inspection routines are supported out of the box:
File permissions check – You didn’t do a chmod 777 on all files, right?
Git modifications check – Is your WordPress revisioned by Git? Then we log uncomitted file changes.
Database collation check – Does your tables have the proper character set and collations?
Site visibility check – Is your website blocking search engines?
Then there’s the following WordPress hook or otherwise user action triggered routines:
Plugin enabling/disabling – Who disabled or enabled that plugin?
User registrations – Logs all user registrations. No more, no less.
User profile updates – Logs all user profile updates, even password changes.
User capabilitiy changes – Who promoted or demoted that user?
Site registrations – Who created that site in your site network?
Site enabling/disabling – Who disabled or enabled that site in your site network?
Javascript error logging – Keep track of javascript errors, even the ones that appears in your visitor’s browsers.
A little configuration is needed to take full advantage of the file permissions and site visibility routines, see installation instructions.
Doing inspections and viewing inspection logs
Login to your WordPress site with an administrator account and navigate to the Angry Inspector page under the ‘Settings/AC Inspector’ menu in the WP admin panel (in network admin if multisite). In here you should see the inspection log and may trigger the scheduled inspection routines manually by clicking the “Inspect now” button. Also take note of the “Inspection routines” and “Action routines” tabs where you among other things may change the log level for each routine. Set log level to ‘ignore’ to completely disable a routine.
Inspect and repair using WP-CLI
First make sure you have WP-CLI installed, see http://wp-cli.org for instructions. Then navigate your commandline shell to your WordPress install directory and issue the following command:
wp angry-inspector inspect
You may also call a specific inspection routine like this (use all lowercase name of class or function without “ACI_Routine_”-prefix and replace underscores with dashes):
wp angry-inspector inspect file-permissions
Any inspection remarks while inspecting with WP-CLI will cause the inspector to look for a possible repair method and prompt you with the question wether you would like to make an attempt at repairing if one is found. Want to skip inspection and go directly for repairing? Here’s how:
wp angry-inspector repair
To call a repair method for a specific inspection routine:
wp angry-inspector repair site-visibility
Please note that for utilizing a repair method like the one for file permissions, you need to run the command as super-user (root) and add –allow-root to your WP-CLI commands, like this:
sudo wp angry-inspector repair file-permissions --allow-root
That’s all there is to it, really. Note that the given log_level option is just a default and may be overridden in the ‘Settings/AC Inspector’ menu in the WP admin panel (in network admin if multisite) like all the other registered inspection routines.
Creating your own inspection routines
Are you skilled in the arts of WordPress development and have a need for a check not covered by the above? Then you should extend the inspector with your own inspection routine! It’s really simple. Here’s an example you can put in your theme’s functions.php or in a plugin (after plugins loaded):
if ( function_exists( 'aci_register_routine' ) ) {
$options = array( 'description' => 'My awesome inspection routine!',
'log_level' => 'warning' ); // Possible values: notice, warning, fatal, ignore
$action = 'ac_inspection'; // Default inspection action run once every 24 hrs
aci_register_routine( 'my_inspection_routine', $options, $action );
function my_inspection_routine() {
$inspection_passed = false;
// Put your inspection code here,
// then log your results like so:
if ( !$inspection_passed ) {
AC_Inspector::log( 'Your WordPress-install did not pass your inspection routine.', __FUNCTION__ );
}
// No need to return anything...
return;
}
}
For a bit more advanced developers, you may also register a class as an inspection routine. The syntax and function used is the same, it’s just a matter of passing the class name instead of a function name. The inspector will by default look for a class function called ‘inspect’ to register as inspection method, otherwise you may add ‘inspection_method’ => ‘your_inspection_function’ to the options array to use any class function you like as your inspection method.
The reason why you would want to register a class instead of just a function is that it gives you the ability to extend the settings for your routine beyond just the log level and maybe even add a repair method to call if the inspection fails (WP-CLI only).
First off, here’s how you extend the settings for your routine (inside your inspection routine class):
public static function settings_field( $options, $args = array() ) {
$routine = $args["routine"];
/**
*
* Input field name convention: aci_options[][field_name]
* Input field id convention: aci_options__field_name
*
**/
?>
Here be extra settings field 🙂
'warning',
'description' => 'My awesome inspection routine!' );
aci_register_routine( 'my_inspection_routine_class', $default_options );
// Optional extra settings fields
add_action( 'my_inspection_routine_class_settings_field', array( 'my_inspection_routine_class', 'settings_field' ), 10, 2 );
add_filter( 'my_inspection_routine_class_settings', array( 'my_inspection_routine_class', 'settings' ), 10, 1 );
Your extra settings fields should now be visible in either the Inspection or the Action routines tab under the ‘Settings/AC Inspector’ menu in the WP admin panel (in network admin if multisite).
For a complete example routine class, checkout the routines/wp_mail.php file in the plugin directory.
As for registering a repair function, it works the same as when registering a class with an inspection method. The inspector looks for a class function called ‘repair’ by default. Override with any class function you like by defining ‘repair_method’ => ‘your_repair_function’ in the options array. However, a repair method will never be called automatically. You need WP-CLI ( http://wp-cli.org/ ) installed and issue the appropriate commands, see “Inspect and repair using WP-CLI” above.
Happy… no wait, angry inspecting! 🙂
