{"id":2774,"date":"2023-02-01T19:14:28","date_gmt":"2023-02-01T22:14:28","guid":{"rendered":"https:\/\/felipeelia.com.br\/?p=2774"},"modified":"2023-02-01T19:14:33","modified_gmt":"2023-02-01T22:14:33","slug":"wordpress-health-status-and-the-new-report-parser-tool","status":"publish","type":"post","link":"https:\/\/felipeelia.dev\/wordpress-health-status-and-the-new-report-parser-tool\/","title":{"rendered":"WordPress Health Status and the new Report Parser Tool"},"content":{"rendered":"\n
What is your WordPress version? And PHP? How many posts do you have? Status reports gather all those information in a single place. Just copy and paste, and answer all the support questions at once. But what do we do when the report is not easy to read?<\/p>\n\n\n\t\t\t\t
Asking or answering the same questions is too boring, everybody agrees. Everybody also agrees that the solution for repeated tasks is automation<\/strong>. If the system knows all the answers, why not get them directly from the source, saving everybody’s time? Status or system reports are meant for this.<\/p>\n\n\n\n If the system knows all the answers, why not get them directly from the source, saving everybody’s time?<\/p>\n<\/blockquote>\n\n\n\n Status report pages are already common in the WordPress ecosystem. Go to a specific page, click on a button, and paste it into a ticket<\/strong>. The report isn’t always that legible but I’ve created a tool to help with that.<\/p>\n\n\n\n Status pages are divided into sections containing lists of key-value pairs. In WordPress, for example, we have the “WordPress” section, and some keys are “Version”, “Site Language”, etc. The copy-and-paste report shared with support follows the same format but it gets really hard to read when the value is too big<\/strong>. Imagine a JSON object, for example.<\/p>\n\n\n\n\n
The Report Parser<\/a><\/em> Tool<\/h2>\n\n\n\n