Search Results for 'update'

Hi Lucian,

Thanks for your quick reply and good luck for next updates 😉

What does this new theme do to the newspaper development?
Will we just see slowed down feature updates or do you plan to only provide security/compatibility releases in the future?
(Maybe i should ask that after seeing the first weeks of Newsmag sales? 🙂

• This reply was modified 11 years by thomaspe.

hi, here is one of the plugins I mentioned which is supposed to help with tracking down where all the dbase queries are going … I’ve started using this recently to double check myself on stuff:

WORDPRESS QUERY MONITOR PLUGIN:

https://wordpress.org/plugins/query-monitor/

Query Monitor is a debugging plugin for anyone developing with WordPress. It has some advanced features not available in other debugging plugins, including automatic AJAX debugging and the ability to narrow down things by plugin or theme.

Here’s an overview of what’s shown:

Database Queries
◾Shows all database queries performed on the current page
◾Shows affected rows and time for all queries
◾Show notifications for slow queries and queries with errors
◾Filter queries by query type (SELECT, UPDATE, DELETE, etc)
◾Filter queries by component (WordPress core, Plugin X, Plugin Y, theme)
◾Filter queries by calling function
◾View aggregate query information grouped by component, calling function, and type
◾Super advanced: Supports multiple instances of wpdb on one page

Filtering queries by component or calling function makes it easy to see which plugins, themes, or functions on your site are making the most (or the slowest) database queries.

Hooks
◾Shows all hooks fired on the current page, along with hooked actions and their priorities
◾Filter hooks by part of their name
◾Filter actions by component (WordPress core, Plugin X, Plugin Y, theme)

Theme
◾Shows the template filename for the current page
◾Shows the available body classes for the current page
◾Shows the active parent and child theme name

PHP Errors
◾PHP errors (warnings, notices, stricts, and deprecated) are presented nicely along with their component and call stack
◾Shows an easily visible warning in the admin toolbar

Request
◾Shows matched rewrite rules and associated query strings
◾Shows query vars for the current request, and highlights custom query vars
◾Shows the queried object details (collapsed by default)

HTTP Requests
◾Shows all HTTP requests performed on the current page (as long as they use WordPress’ HTTP API)
◾Shows the response code, call stack, transport, timeout, and time taken
◾Highlights erroneous responses, such as failed requests and anything without a 200 response code

Redirects
◾Whenever a redirect occurs, Query Monitor adds an X-QM-Redirect HTTP header containing the call stack, so you can use your favourite HTTP inspector to easily trace where a redirect has come from

AJAX

The response from any jQuery AJAX request on the page will contain various debugging information in its header that gets output to the developer console. No hooking required.

AJAX debugging is in its early stages. Currently it only includes PHP errors, but this will be built upon in future versions.

Admin Screen

Hands up who can remember the correct names for the filters and actions for custom admin screen columns?
◾Shows the correct names for custom column filters and actions on all admin screens that have a listing table
◾Shows the state of get_current_screen() and a few variables

Environment Information
◾Shows various PHP information such as memory limit and error reporting levels
◾Highlights the fact when any of these are overridden at runtime
◾Shows various MySQL information, including caching and performance related configuration
◾Highlights the fact when any performance related configurations are not optimal
◾Shows various details about WordPress and the web server
◾Shows version numbers for all the things

Everything Else
◾Shows any transients that were set, along with their timeout, component, and call stack
◾Shows all WordPress conditionals on the current page, highlighted nicely
◾Shows an overview including page generation time and memory limit as absolute values and as % of their respective limits

Authentication

By default, Query Monitor’s output is only shown to Administrators on single-site installs, and Super Admins on Multisite installs.

In addition to this, you can set an authentication cookie which allows you to view Query Monitor output when you’re not logged in (or if you’re logged in as a non-administrator). See the bottom of Query Monitor’s output for details.

Theme works great across all our sites (and has the past year). Usually the culprit with this kind of thing is a rogue plugin not updated to work with WordPress 3.9/4.0 which introduced a lot of changes; or a social media related plugin which has to go out and retrieve data and times out, or some kind of plugin which creates dynamic content by doing dbase queries PER PAGE load and not caching that (such as “related items”, complex Ajax loading of additional content on page scroll, forums, site forms which can be pinged externally and have auto-responders, etc.).

Often the ERROR LOGS for your site can give a specific indication of the error.

There is also a great resource checker plugin for WordPress I shared with somebody the other day here, but forget what that link is — it basically tells you WHICH plugin is taking up all your resources, and allows you to remove those, and/or find alternate solution.

I’m sure Marius or Lucian will have “official response” but thought I’d share that.

We had a site become corrupted the other day (first time since WP 2.6 ?) and the only way I could fix that was to use the “reinstall” WP function in the WP admin, which reset all the permissions properly. Weird. That site just kept crashing on everything like preview of theme option, running any plugin settings, etc.

Not sure that helped; but thought I’d at least give you some moral/mental support 🙂

I’ve run into this too. I create a similar function named child_… and have been lucky enough that all references to the functions are in child-editable files, so I just make them use child_… instead.

In child_… I usually just catch the special case I have in mind and then pass everything on to the parent function again, to prevent having so many revisions in the child theme that it not only survives updates but is impervious to them. :p

What’s that url you are getting a 403 for. I’m not seeing that.

Guess what…. It’s the TAGDiv Speed Booster that’s giving that error. It was 2.1, I went and updated it to 2.5 and the error is still there.

I deactivated it and the error is gone.

Thanks…
But now we will have to do this all over again if we have a theme update 🙂