bruandet

Thanks for reporting the issue.
Since version 1.2, there’s the new custom post input field, hence the list of posts displayed inside the dropdown menu is obsolete now, I’ll remove it in the next version.

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.

It seems that Mercado Pago fixed the problem in their plugin in version 5.7.x, which was released a couple of days ago.

I just installed and activated WooCommerce and woocommerce-mercadopago and saw the same error:

 PHP Fatal error:  Cannot declare class Rest_Client_Abstract, because the name is already in use in wp-content/plugins/woocommerce-mercadopago/includes/module/sdk/lib/rest-client/class-rest-client-abstract.php on line 21

I edited that file and wrapped the whole Rest_Client_Abstract class into that code:

 if (! class_exists('Rest_Client_Abstract') ) {
...
...
...
}

Then I received another similar error:
PHP Fatal error: Cannot declare class MP_Rest_Client, because the name is already in use in wp-content/plugins/woocommerce-mercadopago/includes/module/sdk/lib/rest-client/class-mp-rest-client.php on line 19

I edited that file too and wrapped the MP_Rest_Client class into that code:

if (! class_exists( 'MP_Rest_Client' ) ) {
...
...
...
}

Then, it worked.
If you make those changes, test your plugin to make sure there’s no issues with it.
I have no idea why it tries to load those classes twice.

The profiler can’t work with just a button in the admin bar, because there are some AJAX requests to be processed in the background and so far they are only available from the main profiler page.

The input fields on the profiler page are not saved. Maybe I will add a possibility to temporarily save them inside a cookie for the current session.

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.

@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.

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.

Can you try to update to version 1.1.1 that was released today? It fixed an issue in the AJAX request.
I’m not sure if that’s your problem though, because it should not stop the scan, just throw an error in the PHP log.

I had the same issue due to aggressive caching. I added some extra HTTP headers to prevent caching a couple of days ago and uploaded the patched version into the trunk folder: https://downloads.www.ads-software.com/plugin/code-profiler.zip

Can you try it? Upload it from the “Plugins > Add New > Upload Plugin” menu and replace the current one with that one.

Support for child pages will be available in a couple of days in the next release, as well as support for blogs that do not use permalinks (?page_id=1 etc).

The profiler writes to the wp-content/uploads/code-profiler/ folder. Then, the parser reads and parses those files to create the report. What’s happening is that the parser finds empty files.
That could be due to something that shortcuts the profiler:
* A read-only wp-content/uploads/code-profiler/ directory: it seems unlikely because it works when you profile the homepage.
* A CDN: the profiler sends HTTP header to avoid caching. Most CDN should follow them.
* Opcode cache: Possible, however the profiler disables the opcode cache when running.
* Rewrite rules/permalinks in .htaccess: Maybe you should look at this. Since only the homepage is working (/), there could be some rules shortcutting the profiler when another post or page is requested?

You can check your HTTP logs and search for ?CODE_PROFILER_PRO_ON= to see its request.

I tried your settings with OpenLitespeed and the profiler worked as expected. However, it looks like you’re using CloudFlare. Maybe there’s an issue with it? I made a test with Cloudflare and I had an error message about the profiler’s security nonce, on all pages except the “homepage”.
I added some extra HTTP headers to the code to prevent caching and then it worked.

I uploaded the patched version into the trunk folder: https://downloads.www.ads-software.com/plugin/code-profiler.zip

Can you download it, and upload it from the “Plugins > Add New > Upload Plugin” menu? WordPress will warn you there’s already a copy of the plugin installed, ignore it and click on the “Replace current with uploaded”.

I just tested the LiteSpeed Cache plugin with its default values and didn’t see any issue. But there are a lot of options, one of them could be the problem.
As I can see it has an export/import option, would you mind to export and send your configuration to me ( contact [at] nintechnet [dot] com )? I could test it. If you send it, please enter “Code profiler: szmigieldesign @ wp.org” in the subject.

Also, which PHP version and HTTP server are you using?

This is a known bug/issue in Site Health, I already informed them about it: https://www.ads-software.com/support/topic/does-not-play-well-with-php-sessions/

This affects the test, but shouldn’t affect your blog, i.e., the REST API should be working as usual. In the next version, I’ll add some code to (attempt to) bypass this issue, but I would prefer that Site Health’s developers solve the issue in their code.

Tant mieux ! Merci d’avoir rapporter le bug.

Je vois, JetPack injecte du JS.

* Téléchargez ce fichier: https://plugins.trac.www.ads-software.com/export/HEAD/ninjafirewall/trunk/lib/utils.php
* Copiez-le par FTP dans le répertoire wp-content/plugins/ninjafirewall/lib/ pour remplacer le fichier existant et confirmez-moi si ca fonctionne,