pierre-lannoy / wp-decalog Goto Github PK

I want my to appear among in the supported platforms list. Just like Datadog and Newrelic.

Is there any limitation , technical or legal. Or we can just provide a PR ?

thanks an advance

I'm trying to use DecaLog on my development environment (docker container). Despite setting up the Ray logger, no events arrive on Ray.

Perhaps you should allow variables to be modified or use the ray.php ? Or a better solution? ;)

protected $defaultSettings = [
        'enable' => true,
        'host' => 'host.docker.internal',
        'port' => 23517,
        'remote_path' => null,
        'local_path' => null,
        'always_send_raw_values' => false,
    ];

Describe the bug
I am not sure if this is a usage error, a bug or should be a feature request. So let me know if I need to put this in a different spot.

I have enabled the "database" listener. I expected this to mean that information about database queries (ie. what query and how long it took) would be included in the trace data exporter into Jaeger (or whatever trace solution used).

However, all I see are spans relating to WP Core (presumably the "WordPress core" listener). I expected (perhaps incorrectly) that my spans would have what database queries were triggered and how long they took (in an ideal world it would also include any external HTTP requests and how long they took (what line of PHP triggered the request and what parameters were passed).

I was expecting something similar to what is discussed here (https://woocart.com/blog/slow-wordpress)

To Reproduce
Steps to reproduce the behavior:

1. Use this docker-compose file:

---
version: '3'
services:
db:
  # We use a mariadb image which supports both amd64 & arm64 architecture
  image: mariadb:10.6.4-focal
  # If you really want to use MySQL, uncomment the following line
  #image: mysql:8.0.27
  command: '--default-authentication-plugin=mysql_native_password'
  volumes:
    - db_data:/var/lib/mysql
  restart: always
  environment:
    - MYSQL_ROOT_PASSWORD=somewordpress
    - MYSQL_DATABASE=wordpress
    - MYSQL_USER=wordpress
    - MYSQL_PASSWORD=wordpress
  expose:
    - 3306
    - 33060
wordpress:
  image: wordpress:latest
  ports:
    - 80:80
  restart: always
  environment:
    - WORDPRESS_DB_HOST=db
    - WORDPRESS_DB_USER=wordpress
    - WORDPRESS_DB_PASSWORD=wordpress
    - WORDPRESS_DB_NAME=wordpress
grafana:
  image: grafana/grafana:8.1.6
  volumes:
    - ./ds.yaml:/etc/grafana/provisioning/datasources/datasources.yaml
  environment:
    - GF_AUTH_ANONYMOUS_ENABLED=true
    - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
    - GF_AUTH_DISABLE_LOGIN_FORM=true
  ports:
    - "3000:3000"

jaeger:
  image: jaegertracing/all-in-one:latest
  ports:
    - '6831:6831'
    - '16686:16686'
    - '14268:14268'
volumes:
db_data:

2. Setup Wordpress and install Decalog. Configure Decalog to ship traces to the jaeger instance. Add the jaeger datasource to Grafana.
3. Navigate through the Wordpress site and search through the Spans. Open any of the spans and there is no data surround SQL queries.

Expected behavior
data about SQL queries

Screenshots

Environment (please complete the following information):

Database (MariaDB 10.6.4)
Metatraces listener (DecaLog 3.5.1)
PHP (PHP 7.4.30)
Prometheus-compliant listener (DecaLog 3.5.1)
PSR-3 compliant listeners (DecaLog 3.5.1)
WordPress core (WordPress 6.0.2)

Additional context
Add any other context about the problem here.

Hello,

Is there a way to integrate logs directly from decalog to custom SIEM?

Describe the bug

After updating our Test ENV to Decalog 3.6.0 we got tons of these in our logs:

Uncaught exception (Error): “Call to undefined method WP_CLI::get_logger()“ at ./wp-content/plugins/decalog/includes/plugin/class-initializer.php:64.

To Reproduce
Steps to reproduce the behavior:
Update to Decalog 3.6.0 and run code via WP-CLI

Environment (please complete the following information):

• PHP 7.4.<latest>
• WordPress 6.0.2

In the WordPress listener, it would be better to display plugin real names than their paths.

Is your feature request related to a problem? Please describe.
Metrics are an amazing tool to get insight into an application. But with the major analytics platforms charging by the number of metrics collected, it is a matter of cost to decide which metrics to actually trace. There are several metrics which create an exponential growth in the number of traced metrics.

Describe the solution you'd like
Within admin.php?page=decalog-settings&tab=metrics allow to enable / disable the single metric. This will allow one to limit the metrics to those really required and thus controlling the created costs by the metrics.

Describe alternatives you've considered
Select the metrics to submit within the configured metrics provider. As it might be different for each provider / connection.

Additional context
We use Datadog. With the Decalog default enabled and metrics submitted on a Multisite Environment we very quickly had several hundred metrics billed there. We then disabled the metrics collection for cost reason.

Describe the bug
We do tests with the PHP8 upgrade at the moment. After we upgraded the installation to 8.1 our logs were flooded with the "Metric not found" Error above for each and every WP-CLI run.
I hope and believe it is related. But the PHP upgrade is the only recent change which could have triggered this. We were able to reproduce this with Decalog 3.6.0 as well as 3.6.2 against Datadog. We have DD Events and DD Metrics configured and setup against Datadog.
When we pause / disable DD Metrics the error disappears.

Here is the stacktrace which oddly ends with decalog_run :-/

decalog_run,
include_once(`/plugins/wp-decalog/decalog.php`),
require(`wp-settings.php`),
WP_CLI\Runner->load_wordpress,
WP_CLI\Runner->start,
WP_CLI\Bootstrap\LaunchRunner->process,
WP_CLI\bootstrap,
include(`phar:///usr/local/wp/wp/vendor/wp-cli/wp-cli/php/wp-cli.php`),
include(`phar:///usr/local/wp/wp/php/boot-phar.php`)

To Reproduce
Steps to reproduce the behavior:

1. Enable and configure DD Metrics
2. Switch a running site from PHP7.4 to PHP8.1
3. Run any command on WP-CLI

Expected behavior
No error at all :-) Or an idea / hint how to do something against this.

Screenshots

Environment (please complete the following information):

• PHP version: 8.1.2
• WordPress MU 6.0.1 and 6.0.3 tested
• WP-CLI 2.6.0
• Decalog 3.6.0 and 3.6.2

Describe the bug
Perfopsone-consoles functionality break under PHP 8.x.x, even though https://wordpress.org/support/topic/php-8-fatal-error-3/ states it should be functional.

To Reproduce
Steps to reproduce the behavior:

1. Run with PHP 8.0 or PHP 8.1
2. Go to ./wp-admin/admin.php?page=perfopsone-consoles
3. Select any of the options available, such as Live API Calls, Live Events, or Vibes Signals.
4. Endlessly loops listening for API connection

Expected behavior
It connects to the API.

Screenshots
Broken: https://i.imgur.com/FdQHn2y.png
Expecting: https://i.imgur.com/UGAM7gJ.png

Environments:
Test server:

• nginx 1.22.0
• PHP version: PHP 8.0.x and 8.1.x. Got it to work on PHP 7.4.32.
• WordPress 6.0.2
• Other info: Nothing

Production server:

• nginx 1.22.0
• PHP version 8.1.x
• Wordpress 5.9.4
• Too many plugins...

Additional context
Was mislead about the plugin's status since https://wordpress.org/support/topic/php-8-fatal-error-3/ stated it should be working on PHP 8.

Hey @Pierre-Lannoy,

just FYI: https://decalog.io/ seems to be broken. All links lead to the main page only.

Have a great weekend!

Jan

I'd like to utilize your plugin for syslog forwarding to SIEM. This tool has a cloud hosted syslog collector which should be capable of receiving the logs given your formatting. The issue with this is that it currently only accepts authenticated messages, i.e. with a Token.

Do you think it would be possible to update this file (SyslogHandler.php) potentially on lines 22 & 41 to pass an authentication token? I haven't fully traced your plugin yet, but am curious if you've run into this issue or if I am misusing your tool.

I'd be happy to help with this, curious what your thoughts are.

Thank you,
MG

Hey @Pierre-Lannoy,

more of a question but something we came along trying to do some housekeeping in datadog.

Within

This helps us optimize mostly the cost structure as well as little bit reducing log bloat in DD ;-).

Just want to get your resoning behind this. As I belive this is intentional as always :-)
If you agree, I would at least move Decalog / PHP notice to DD notice. If not even setting all of the to their according DD log levels. But that seems a bit "radical" to me at the moment with no actual need.

Have a great day and all the best as usual :-)

Is your feature request related to a problem? Please describe.
Currently the menu pages are created at PHP_INT_MAX and PHP_INT_MAX -1 in the finalize method. This makes it virtually impossible to remove the pages using own code.
We want to remove the Dashboard (perfopsone-dashboard) for non Super Admins in Multisite, as we do not want "Site owners" = Single Admins to access POO / Decalog in any way. In addition to that, with our current settings, the Menu page is simply empty for single site admins. There is just the top level entry, but no submenu entries.

This is the relevant code:

Describe the solution you'd like
Decrease the priority to reasonable values. Set it as high as necessary, but as low as possible (like 100, 200, etc. ?). With this, one could remove the pages using admin_menu with a higher priority.

Describe alternatives you've considered
Add a filter to disable the POO Dashboard. Currently the Top Level entry is always created and there is no way to disable this. A filter here would be also a possible solution:

Additional context
View for Single Site Admin:

Site 247 integrations would be great

Design a logo for the plugin.

Write readme.txt file, see https://wordpress.org/plugins/readme.txt.

Describe the bug
Can't choose which Listeners to show

To Reproduce
Steps to reproduce the behavior:

1. Go to wp-admin/options-general.php?page=decalog-settings&tab=listeners
2. Switch from "All available listeners" to "Selected Listeners"
3. Optionally select some listeners. Save.
4. "All available listeners" option will be selected again.

Expected behavior
On step 4, it should show "Selected Listeners".

Environment (please complete the following information):

• PHP version: 7.2.5
• WordPress version and flavour 5.3.1

Additional context
I've just installed the plugin, I want to disable all listeners and add just my own listener for custom events in my website.

Describe the bug
When I try to run a CLI command 'wp log listener disable wpdb' it returns a message 'Invalid listener id supplied' and exit.
The 'wpdb' listener definitely exists, as it is a standard one and it is shown in the listeners list after running 'wp log listener list'.

The root cause is in the line 1146 of includes/features/class-wpcli.php
https://github.com/Pierre-Lannoy/wp-decalog/blob/master/includes/features/class-wpcli.php
Looks like the $listeners array is always empty in that condition, so the $uuid becomes empty for each command with arguments.

To Reproduce
Steps to reproduce the behavior:

1. Open any tool to run a WP CLI.
2. Run the command: wp log listener disable wpdb
3. See the error message

Expected behavior
Disabling the specified listener, in case of disable command.
Enabling the specified listener, in case of enable command.

Environment (please complete the following information):

• PHP version: 7.4.30
• WordPress version: WordPress MU 6.0.2
• Decalog version: 3.5.1

Is your feature request related to a problem? Please describe.
Database spans from Dacalog are not recognized by APM dashboards.

Describe the solution you'd like
We would like to make Decalog OTel-compatible. OpenTelemetry has a set of semantic conventions for tagging a span, which is recognized by some APM dashboards.

Describe alternatives you've considered
We can run a "shim" between Decalog and OpenTelemetry backends, but that’s extra amount of work and may be difficult for most users.

A potential solution is introducing hooks into Decalog, to let users modify tags of all traces.

Additional context
https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/

A logger which uses are "standard" and which implements PSR\Log\LoggerInterface ;)

Describe the bug
Happy new year :-)

We have reproducible "Critical" Error log entries in Datadog for this AJAX endpoint. It seems that you already added some code to catch this in the past (2y ago) which doesn't seem to work (anymore?).

🟥 Critical [0] Permalink:

WP Core handles AJAX Calls in wp_die slightly different than other calls by defaulting to status 200 instead of 0. Maybe it's a good idea to replicate this handling and add a check for wp_doing_ajax() to your wp_die_handler instead of the hack in there?
Then: If is ajax, only log an error if the $args['code'] is > 400 ?

What do you think?

To Reproduce
Steps to reproduce the behavior:

1. Open any "New " like "New Post"
2. Enter something into the title and leave the input field
3. Check your DEV tools for ajax calls. It should return "Permalink: " with status 200
4. Check your Logs, you should have a critical with exactly this content ("Permalink: ") with code "0"

Expected behavior
Log Permalink calls / WP AJAX calls with status code 0 as debug instead of critical.

Screenshots

Environment (please complete the following information):

• PHP version: 7.4.24
• WordPress version and flavour [e.g. WordPress MU 5.2]: MU 5.8.3

Requires PHP: 7.2

We could include Composer's autoloader AND put all of our classes in 1 directory. Now there are two orphans

• ./public/class-decalog-public.php
• ./admin/class-decalog-admin.php

Of course we still need our own autoloader as this project follows WPCS which - I think - will be deprecated as soon as core gets a namespace.

Write a comprehensive README.md (and page header) to provide:

• description of the plugin
• ways to use it
• rules to contribute

To adhere to WP security rules it's needed (but not enforced) to use wp_remote_* function instead of direct curl calls. Currently Monolog go through curl, so there's something to change ;)

Add licenses files to each embed libraries.

Is your feature request related to a problem? Please describe.
We currently profile our WP setup. Decalog popped up as a source of too much rendering-time on nearly all requests.

See the profiling chart on the right in light and dark green. In this request the CoreListener::plugin_close causes about 40% of the rendering time of that page. All Decalog is at about 52% of this single request. The remaining time comes from DatabaseListener::db_monitoring_close.

The source is within the CoreListener::plugin_close with its calls to plugin_update and theme_update causing HTTP requests to the external repos. As we all know that HTTP requests are bad and evil slow these operations should be used rarely and never in frontend or AJAX requests. DatabaseListener::db_monitoring_close does uncached SQL queries. Even something I would like to skip performancewise ;-).

Describe the solution you'd like
There are two solutions coming into my mind:

1. General approach: We do not have any metrics provider configured by choice in this environment. So why are metrics even collected? The plugin_close method as well as db_monitoring_close only work on counters which are only relevant if a metric provider is configured, correct?
   Could we add a layer of "check what to collect before collecting it"? Like collect_metrics():true|false and collect_events():true|false and add them around the proper functions before executing and hooking stuff? Should reduce the footprint of the plugin to the only required level.

2. For this particular case: Limit the execution of the plugin functions to authenticated admin calls with the capabilities to actually update plugins.

Additional context
WPMU 6.0.2
PHP 7.4.

Describe the bug
Hi, we are trying to set up Prometheus metrics as explained in https://perfops.one/a-almost-free-observability-platform-part-2/ but we are not able to get metrics in Grafana Cloud.

To Reproduce
Steps to reproduce the behavior:

1. Set Prometheus endpoint in Decalog Plugin. Wordpress is deployed inside Kubernetes cluster exposed by a service
2. Set Grafana Agent inside the cluster with the following config:

    metrics:
      wal_directory: /var/lib/agent/wal
      global:
        scrape_interval: 60s
        external_labels:
          cluster: 'clustername'
      configs:
      - name: integrations
        remote_write:
        - url: https://prometheus-prod-05-gb-south-0.grafana.net/api/prom/push
          basic_auth:
            username: 'username'
            password: 'password'
        scrape_configs:
        - job_name: decalog/scrapping
          static_configs:
            - targets: ['service-name']
              labels:
                process: 'agent'
          metrics_path: "/wp-json/decalog/v3/metrics?uuid=XXXXXX"

3. Go to grafana.com
4. Only scrape_duration_seconds metrics are shown with the selected labels

Expected behavior
All metrics send by Decalog (those with wordpress_ prefix) are expected to be present. We are able to get Prometheus metrics in local Grafana using Push Gateway, but with Grafana Cloud we cannot use it.

Environment (please complete the following information):

• PHP version:PHP 7.4
• WordPress 6.1

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
Trace and span context can be propagated through HTTP header(s). W3C has a recommended standard compatible with OpenTelemetry, while older Jaeger-compatible clients are using Uber's original format. If possible, we should support both:)

Describe the solution you'd like
Parse the HTTP headers accordingly and, if the content is valid, propagate the trace by overriding the default settings (trace id/parent span id/sampled/...).

Describe alternatives you've considered
Simply ignore it like what we're doing now. The full semantics is rather complex, so it may not worth the effort.

Additional context
https://www.w3.org/TR/trace-context-1/#trace-context-http-headers-format
https://www.jaegertracing.io/docs/1.22/client-libraries/#tracespan-identity

Is your feature request related to a problem? Please describe.
I would like to export a new metric from the core class. At the moment I can export wordpress_core_wordpress_plugin_updatable but there is no metric for themes. I've set up a prometheus endpoint and a grafana dashboard. An alert is triggered, when a plugin is updatable. I would like to implement the same process for a theme update.

Describe the solution you'd like
I would like to have an additional Core Class metric, something like wordpress_core_wordpress_theme_updatable.

Describe alternatives you've considered
No alternatives considered at the moment.

Is your feature request related to a problem? Please describe.
We are investigating using a vendor agnostic collector in our pipeline and would like to send events to a generic HTTP endpoint, since that seems to be a method that is widely supported by collectors like Vector, fluent bit, and Open Telemetry.

Describe the solution you'd like
A new logger that specifies an HTTP:port endpoint, auth method (basic/bearer), and ideally a format choice (json/syslog/gelf/protobuf/avro).

Describe alternatives you've considered
I'm not sure whether any of the existing loggers can be used for this purpose. The fluentd and syslogd loggers will send to a url:port.

Is your feature request related to a problem? Please describe.
Currently there is the siteid and the sitename within the meta of an event log entry. The name may not be easily matchable to a single site in a multisite environment. The id again requires an additional lookup step to identify the origin site. Having the domain would allow a direct access to the origin site (/wp-admin for example). In addition to that the domain is more stable than the name of a site and thus better suited as a readable identifier within tools like Datadog. Currently one would have to know the ID to create stable filters / queries. The domain would be better.

Describe the solution you'd like
Add a new field sitedomain containing the sites domain.

Describe alternatives you've considered
None. Small change, big effect

Describe the bug
Hey @Pierre-Lannoy, its me again ;-) Hope you are doing well!

Since the last update to decalog 3.4.1 we encounter HTML encoded entities in our DataDog logs:

Alert [1] Fatal error (E_ERROR): “Maximum execution time of 45 seconds exceeded“ at `./wp-content/plugins/decalog/includes/system/class-sharedmemory.php:149`.

The “ and ” are new. It also happens for other HTML encodeable entities whenever they are part of the submitted log message.

I am quite certain this was not the case before we updated to 3.4.1. Yet I cannot completely rule out a change on Datadog side.

To Reproduce
Steps to reproduce the behavior:

1. Connect against Datadog
2. Break something and trigger an error

Expected behavior
The string should appear in DataDog in its natural beauty without these crude transformations.

Is your feature request related to a problem? Please describe.
Currently DecaLog defaults to use the name "WP" as service name in Jaeger. Sometimes we may want to customize the name (since it’s displayed on the tracing dashboard) or avoid collision between multiple WordPress instances.

Describe the solution you'd like
Add a new "service name" setting for Jaeger tracers.

Describe the bug

When for whatever reasons the sitemeta `decalog_loggers' gets corrupted, the site is doomed in an unusable state as long as decalog is enabled. Only way out: Move / Delete the Decalog plugin folder.

Happened to us when our Webservers lost connection to their DB servers due to a network outage. Seemd to be very bad timing as this one value was left filled with garbage. After the connection came back, all sites were in Fatal Error state.

I know, It's en edge case. But it is one that really hurts... Took us some time to figure out what actually was broken as our logging was broken too ... obviously ;-)

PHP Fatal error:  Uncaught Error: Call to a member function error() on null in /wp-content/plugins/decalog/includes/listeners/class-phplistener.php:350
Stack trace:
#0 [internal function]: Decalog\Listener\PhpListener->handle_exception(Object(Error))
#1 {main}
  thrown in /wp-content/plugins/decalog/includes/listeners/class-phplistener.php on line 350
Fatal error: Uncaught Error: Call to a member function error() on null in /wp-content/plugins/decalog/includes/listeners/class-phplistener.php:350
Stack trace:
#0 [internal function]: Decalog\Listener\PhpListener->handle_exception(Object(Error))
#1 {main}
  thrown in /wp-content/plugins/decalog/includes/listeners/class-phplistener.php on line 350

To Reproduce
Steps to reproduce the behavior:

1. Configure decalog
2. Go to the DB table wp_sitemeta search for decalog_loggers
3. Put something invalid like A.3.0 in there (there should be a serialized object / array in it in a valid case)
4. If the WordPress Fatal Handler "rescues" you, you are lucky :) If you have it disabled to handle errors yourselves, you end up in this trap. Maybe you will end up there anyway when decalog tries to log the fatal caused by itself 🤔

Expected behavior
Only initialize decalog if all required settings are there AND contain valid data. If invalid data is found, delete, skip, ignore or reset that data instead of continuing initialization with broken data. Or deactivate the plugins. Self-Healing should be technically easy in this case.

Environment (please complete the following information):

• PHP version: 7.4.24
• WordPress version and flavour WP MU 5.8.3
• Decalog: 3.3.0 (update planned next week)
• Other info: WP Fatal Error Handler disabled

Best Regards!

Describe the bug
I am unable to configure the Grafana Cloud Traces logger. The best result I could get was an Error 405: Method not allowed.
The Grafana Cloud Events logger works fine.

To Reproduce
Steps to reproduce the behavior:

1. Add a new Grafana Cloud Traces logger.
2. Configure it with: sampling = 100%; format = Zipkin V2; Service URL = https://grafana_tempo_host:port
3. Do something on your site
4. Check logs (You need to have a logger configured). You will have warnings like: message="Pushing traces to https://host:port => Method Not Allowed"

Expected behavior
Traces are sent correctly.

Environment (please complete the following information):

• PHP version: PHP 8.1
• WordPress version and flavour: 6.3.1

Additional context
At first I thought that authentication was missing as Grafana Cloud mentions using basic auth with api key as password for Tempo.
I tried setting the URL as: https://id:api_key@host:port but that does not change anything. Trying out some API calls to https://: I've seen that only GET request are accepted, all other request give an Error 405 Method Not Allowed.
I tried following this tutorial: https://perfops.one/a-almost-free-observability-platform-part-1/ but it omits the most crucial part - the configuration - and simply tells me the Sending Traces page has all the config info I need.

// UPDATE
Describe the bug
The logging of a manual opcache restart is triggered frequently as the compare is only capable of handling a single server. When there are more servers (cluster setup) the state in the WP site meta only reflects one server. Comparing the states of other running servers leads to false assertions and false logging.

Steps to reproduce the behavior:

1. Run a single WordPress installation with a shared DB on two (or more) servers
2. Trigger a manual opcache_reset on one of the servers
3. The log will then be flooded with the false positive message due to the compare of manual_restarts => 0 (WP Site Meta) with manual_restarts => 1 (return of opcache_get_status(false) ) or the other way around - whenever the server with the other value executes code.

Fix: Store the Opcache status with a server identifier like the hostname

Quickfix: Restart php-fpm to align the status counter

Write all details regarding developing a listener and uses of levels.

Failure to send logs to Elastic 8

Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47

Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47

Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47

Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47

Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47

Fatal error: Uncaught Error: Call to a member function error() on null in /var/www/html/wp-content/plugins/decalog/includes/listeners/class-phplistener.php:350 Stack trace: #0 [internal function]: Decalog\Listener\PhpListener->handle_exception() #1 {main} thrown in /var/www/html/wp-content/plugins/decalog/includes/listeners/class-phplistener.php on line 350

Fatal error: Uncaught Error: Call to a member function log() on null in /var/www/html/wp-content/plugins/decalog/includes/listeners/class-phplistener.php:327 Stack trace: #0 [internal function]: Decalog\Listener\PhpListener->handle_error() #1 /var/www/html/wp-includes/functions.php(6031): trigger_error() #2 /var/www/html/wp-includes/functions.php(5975): wp_trigger_error() #3 /var/www/html/wp-includes/query.php(882): _doing_it_wrong() #4 /var/www/html/wp-includes/robots-template.php(93): is_embed() #5 /var/www/html/wp-includes/class-wp-hook.php(324): wp_robots_noindex_embeds() #6 /var/www/html/wp-includes/plugin.php(205): WP_Hook->apply_filters() #7 /var/www/html/wp-includes/robots-template.php(32): apply_filters() #8 /var/www/html/wp-includes/functions.php(3841): wp_robots() #9 /var/www/html/wp-content/plugins/decalog/includes/listeners/class-corelistener.php(1253): _default_wp_die_handler() #10 /var/www/html/wp-includes/functions.php(3763): Decalog\Listener\CoreListener->Decalog\Listener{closure}() #11 /var/www/html/wp-includes/class-wp-fatal-error-handler.php(239): wp_die() #12 /var/www/html/wp-includes/class-wp-fatal-error-handler.php(154): WP_Fatal_Error_Handler->display_default_error_template() #13 /var/www/html/wp-includes/class-wp-fatal-error-handler.php(58): WP_Fatal_Error_Handler->display_error_template() #14 [internal function]: WP_Fatal_Error_Handler->handle() #15 {main} thrown in /var/www/html/wp-content/plugins/decalog/includes/listeners/class-phplistener.php on line 327

I use version 8.2 of PHP.
From WordPress version 6.4.3
From the last edition of the Decalog
But the above error exists for.

Thank you for your guidance.

Is your feature request related to a problem? Please describe.
Hey @Pierre-Lannoy :-)
As a follow up to #24 we took some time to evaluate the solution implemented there. In general it does what it should and prevents any exceptions from happening. But the current implementation leads to resetting the configured loggers whenever the failsafe triggers. It happens surprisingly often whenever an attached object cache might need some time to flush. So the value does not return correctly for <1s. But that's enough to trigger the failsafe.

Describe the solution you'd like
We propose a simple solution. By removing the option_save calls all the failsafe and default logic will happen only in memory. Unless someone actually changes the logger config manually and thus stores the new values intentionally. This will prevent unwanted resets of the actually configured loggers.

Describe alternatives you've considered
We considered persistent default loggers configured within the wp-config.php as constants. This would require PHP 7+ and knowledge of the internal data structure of a logger config. As one would have to duplicate it into the config. This default logger config could then be merged into the loggers object if missing. As you do already with the shared memory logger.
This solution would require more code then the current approach ;-) But it would also be a possible solution for this.

Additional context
🌻

Is your feature request related to a problem? Please describe.
OpenTelemetry is a new and widely adopted standard in distributed tracing. Many well-known backends are OTLP-compatible now, so adding OTLP support will unblock new backends as well as improving already-supported backends like Jaeger.

Describe the solution you'd like
Implements OTLP support and add a new OpenTelemetry-compatible backend support.

Describe alternatives you've considered
Don’t add OpenTelemetry support at this time. OTLP heavily uses Protobuf, which may be troublesome.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
If pre_clear_scheduled_hook returns anything other than null the logger logs:

$this->logger->notice( sprintf( 'A plugin prevented the "%s" event to be cleared.', $hook ) );

Yet this message is wrong. In our case we replaced wp-cron with Cavalcade. The WordPress Docs states:

For plugins replacing wp-cron, return the number of events successfully unscheduled (zero if no events were registered with the hook) or false if unscheduling one or more events fails.
https://developer.wordpress.org/reference/hooks/pre_clear_scheduled_hook/#description

Thus an INT return value indicates that there is some wp-cron replacement running. Thus the Log message is misleading.

This kind of has to be considered for all schedule related hooks. If an external cron system is running, many filters / actions behave slightly different. This are the relevant hooks: https://developer.wordpress.org/reference/files/wp-includes/cron.php/?post_type%5B%5D=wp-parser-hook

To Reproduce

1. Install Cavalcade
2. Call anything unscheduling events like wp_clear_scheduled_hook( 'wp_version_check' );
3. Check the Logs

Expected behavior
One of the following:

1. Don't log if the return is != null as you cannot be sure that there isn't an external cron replacement
2. Log according to INT return values that some external cron replacement did something
3. Check for certain known plugins (like Cavalcade) and log accordingly using an "Alternate WP-Cron Mode"

Environment (please complete the following information):

• PHP version: 7.4.23
• WordPress version and flavour 5.8 MU
• Other info: Cavalcade (Cron Replacement)

Best regards,

Jan

Describe the bug

5 parameters configured, API only offers 4:
https://developer.wordpress.org/reference/functions/wp_clear_scheduled_hook/

    $pre = apply_filters( 'pre_clear_scheduled_hook', null, $hook, $args, $wp_error );

Environment (please complete the following information):

• PHP version: 7.4.23
• WordPress version and flavour MU 5.8

Best,
Jan

Is your feature request related to a problem? Please describe.
The Jaeger endpoint I’m given is shared by multiple users, and it will classify different applications by token tag. Currently wp-decalog cannot specify custom tags, so I’m not able to use the service.

Describe the solution you'd like
Allow users to set custom Jaeger tags.

Describe alternatives you've considered
Can’t think of any alternative yet.

Additional context
I’ve opened a PR on the Jaeger client library for supporting client-level tag configuration. Before that work is done, we can workaround by setting the tags on each spans.

Hi all!,

Im currently testing the plugin, so far I saw how powerful it is by integrating with with Loki, but with prometheus integrations I wasn't as lucky. Im always getting a not found error when trying to push metrics to a prometheus endpoint, Im using the same exact endpoint for remote_write other prometheus instances. There is no much information in the logs aside of that not found error (404), so Im not sure what is wrong with the endpoint url, the domain and port, or the path. And regarding exposing metrics, I wasn't able to find any documentation on the endpoint and path the metrics are exposed.

This is an amazing tool. This is not really a bug request, I just wanted to know if there is any documentation on how to setup the prometheus integrations.

Thanks a lot in advance!