Improvement

Support for any URL and basic authentication password are planned for the next release.
I’m not sure about WPML, because it’s a premium plugin.

Great!

Multilingual plugins (WPML, Polylang etc) was a suggestion to see and better profile slow function and callers in these plugins, maybe not present on default language only.

Some other feature suggestions:
Filter by Name to not only search to see all profiles by a plugin. Easier than using search or sortby.
Option to profile more admin backend pages like loading pages to edit with support for cpt. Here there is normally bottlenecks and slow scripts from plugins.

• This reply was modified 2 years, 10 months ago by Rookie.

Yes, profiling admin pages would be really helpful. The Dashboard and Posts/Pages especially. Thank you.

@joegasper You can do that:

* Select “Page to profile > Admin backend” and you can choose among several pages (Dashboard, Posts, Plugins etc).

* If you want to profile a specific page in the backend such as a plugin page (e.g., https://example.com/wp-admin/admin.php?page=some-plugin), paste the URI inside the “Page to profile > Custom post type/URL” input field. Make sure also to select “Run profiler as > Authenticated user” because only an authenticated admin can access those pages.

@bruandet Kudos for this amazing plugin, I love it.

@alriksson I think you can already profile the default and other languages. It’s enough you set a custom URL for the other languages. If for example, you have https://your-domain.com/sample-page/ and https://your-domain.com/de/sample-page/ or whatever you have in the URL for the other language, profiling the URL related to the other language you should do be able to profile that language.

@bruandet I think it’s also interesting to profile fewer plugins without globally deactivating them. Sometimes you need to compare for example 3-4 plugins but you have no wish to disable all the others if you have a lot of them. Sometimes a plugin is heavier if a third plugin or a certain theme is active. I think isolating plugins would be great. For example, a certain theme may be light, then you install WooCommerce, and the same theme loads a lot of code for the integration with WooCommerce. Or maybe a plugin has some action hooks that are triggered only when a third plugin is active.
I have a question about that. If plugin A has a certain action hook and plugin B hooks on that action, how does your plugin take it into account? Is the consumption measured on plugins A or B?

Anyway, with Freesoul Deactivate Plugins you can isolate the plugins for the profiling.
If you activate FDP and go to Custom URLs => Frontend URLs, and use the match *CODE_PROFILER_ON* you can load only the selected plugins during the profiling process. I have right now tested it and it works. You will see the chart only with the selected plugins, and the other plugins will not run during the profiling.
I’m the author of Freesoul Deactivate Plugins. I will add some code to FDP for having an additional tab in your settings page when FDP is also active and give the possibility to uncheck some plugins. Now with your plugin is very easy to compare plugins. Thank you very much for this great plugin!

Soon or later I will do the integration that I mentioned because I will use it myself many times. If you have also other ideas about possible integrations and you are interested, let me know.

I had plans to add a similar feature that would disable or enable plugins, as well as switch between themes while profiling without affecting users visiting the site. I will wait and see how you want to implement that with your plugin. If that works well, there’s no need for me to add the same feature.

I didn’t try your plugin yet but I’ll test it later this week. It’s a great idea. For instance, I often see plugins that are supposed to work in the backend only but load all their classes during the init() hook and hence slow downs massively the frontend for no reason at all. With your plugin, a user can easily prevent it from running on the frontend.

The time is “exclusive”, i.e., if the code is executed inside plugin A, it will be assigned to plugin A, as oppose to “inclusive”. In the pro version, it’s possible to see the caller of each method/function and that helps to understand what’s going on, but not in the free version. Maybe I’ll add a simple call-tree that will help to understand the execution flow between all plugins.

Thank you for your answer @bruandet

The PRO version looks very interesting.

I will let you know as soon as I add the integration.

Hi @bruandet

I’ve added the integration with your plugin. At the moment you can find it only with the beta version that you can download here: https://downloads.www.ads-software.com/plugin/freesoul-deactivate-plugins.1.8.9.0.4.2.zip

Here you will find a short description: https://freesoul-deactivate-plugins.com/profile-your-website-with-code-profiler-and-freesoul-deactivate-plugins/

In case somewhere in your plugin you want to link the page to select the plugins you can use the link admin_url( ‘?page=cp-fdp’ ). I haven’t seen any filter hook in your plugin, so at the moment it’s linked only in the FDP navigation.

At the moment you can’t select a different theme, but maybe in the future, it will be possible.

PS. thanks to your plugin I realized that it was possible to reduce the execution time of FDP ?? The beta version is faster in terms of execution time.

Let me know of any kind of suggestion that can improve the integration.

I tested the beta version of FDP. At first, it didn’t work but I was using the pro version of Code Profiler. I made some changes to 4 files so that it can work with both versions:

freesoul-deactivate-plugins/admin/templates/partials/eos-dp-navigation.php L71:

<?php if( defined( 'CODE_PROFILER_MU_ON' ) || defined( 'CODE_PROFILER_PRO_MU_ON' ) ){ ?>

freesoul-deactivate-plugins/admin/eos-dp-admin.php L637:

if( defined( 'CODE_PROFILER_MU_ON' ) || defined( 'CODE_PROFILER_PRO_MU_ON' ) ){

freesoul-deactivate-plugins/integrations/code-profiler.php L62:

   <a type="button" class="button" title="<?php esc_html_e( 'Code Profiler','eos-dp' ); ?>" href="<?php
      if( defined( 'CODE_PROFILER_PRO_MU_ON' ) ) {
         echo admin_url( '?page=code-profiler-pro&cptab=profiler' );
      } else {
         echo admin_url( '?page=code-profiler&cptab=profiler' );
      }
   ?>"><?php esc_html_e( 'Code Profiler','eos-dp' ); ?></a>

freesoul-deactivate-plugins/mu-plugins/eos-deactivate-plugins.php L59:

if( isset( $_REQUEST['CODE_PROFILER_ON'] ) || isset( $_REQUEST['CODE_PROFILER_PRO_ON'] ) ){

L287:

if( isset( $_REQUEST ) && !empty( $_REQUEST ) && !isset( $_REQUEST['eos_dp_preview'] ) && !isset( $_REQUEST['show_disabled_plugins'] ) && !isset( $_REQUEST['fdp_post_id'] ) && !isset( $_REQUEST['fdp_assets'] ) && !isset( $_REQUEST['fdp-assets'] ) && !isset( $_GET['fbclid'] ) && !isset( $_GET['site_in_progress'] ) && !isset( $_REQUEST['eos_dp_debug_options'] ) && !isset( $_REQUEST['CODE_PROFILER_ON'] ) && !isset( $_REQUEST['CODE_PROFILER_PRO_ON'] ) ){

L604:

if( isset( $_REQUEST['CODE_PROFILER_ON'] ) || isset( $_REQUEST['CODE_PROFILER_PRO_ON'] ) ){

When you release the final version, I’ll add some instruction to the “FAQ” tab about how to use both plugins together.

Hi @bruandet

really thank you for your corrections.
I’ve implemented them, and the new version 1.8.9.0.5 is public now.

It’s working perfectly.
I will likely release a new version later this week and I’ll add some instructions explaining how to use both plugins.

Perfect. Thank you for the information @bruandet