First Impressions

  • Resolved Brian Henry

    (@brianhenryie)


    2 years, 2 months ago

    Hey,

    I’m just trying this out now – you posted it in the FB group — it seems to be very promising. My thoughts…

    It says, beside a toggle, at the top left:

    Error Logging: Disabled on Sep 21, 2022 - 00:13:13

    but I am 100% certain error logging is enabled, in wp shell:

    wp> WP_DEBUG
=> bool(true)
wp> WP_DEBUG_LOG
=> bool(true)

    It also says:

    Log file: /chroot/wp-content/uploads/debug-log-manager/domain_202209210713_debug.log

    And I understand that to be a courtesy of the plugin, to obscure and protect the log file, but my hosting company already protects the standard wp-content/debug.log path. So now I’m worried my (managed WordPress) hosting company won’t be able to find and read my logs quickly when I need them.

    OK: Then I clicked the toggle and it said ~”log entries have been copied”. I’m not sure does that mean the polling for new entries duplicates the original wp-content/debug.log

    The UI’s “Show X entries” being “10” is not very useful. Yes, often the most recent 10 lines are the ones that matter, but I don’t think 100 would be a huge performance hit.

    Overall, very good work. Beyond what you’ve done, I think there’s a lot of value in annotating the logs, e.g. link directly into Plugin File Editor to the problem file. Or if we had some convention for logging users, e.g. instead of log “brianhenry”, it should be logged “wp_user:228” and then the log library could link to the actual user profile in the middle of the logs.

    The top log in my list is:
    Undefined array key "plugin" in /path/to/ninja-forms/includes/Integrations/EDD/class-extension-updater.php on line 189 … I imagine that’s a message thousands of us have seen. It would be great if there was a service that could mute that error for me once we know someone in the community has fixed it (basically WP.org should be more like GitHub and less like an FTP site).

    Yolo! Thanks, I’ll be using this!

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Bowo

    (@qriouslad)

    Hey @brianhenryie !

    Thanks for dropping by here with your first impressions!

    First off, I haven’t tested this on (and make it work / compatible with) managed hosting and planning to do that in the next phase. The disable/enable ‘miss’ is probably caused by this, i.e. the plugin unable to properly update wp-config.php due to the host’s access settings for that file. Another user asked to make this work with GridPane. What’s the one you’re on?

    As for your feedback:

    1. “Log entries have been copied” is for the 1st time WP_DEBUG is enabled via this plugin. Supposedly, a successful write/update to wp-config.php with the WP_DEBUG constants coming from the plugin, would then be followed by detection of existing debug.log file in the most common default location(s), and then the copying of log entries from that file to the debug.log file generated by the plugin. With managed hosting, this flow is not solid yet, i.e. the copy may have happened, but the wp-config.php constant values are not properlly updated to use the newly generated debug.log file.

    2. 10 vs 100 entries… I like 100 too, but I’m thinking of new users. 10 allows them to see the whole of the UI, including the “clear log” button at the bottom, which I think makes for a better, less overwhelming UX.

    3. On annotating the logs… totally. It’s been on my mind too. I have code I can potentially reuse from my other plugin, Code Explorer, but yes, keep the ideas coming, and maybe, code too.

    4. On a service that identifies fixed issues. Probably beyond my / this plugin’s realm in the near future. But hey, maybe if it’s needed, someone ought to go build it?

    Let me know your further impressions as you use this some more.

    Cheers,
    Bowo

    Thread Starter Brian Henry

    (@brianhenryie)

    > (47 occurrences logged)

    I love it.

    I’ve been thinking about how to do that intentionally when logging myself. I was thinking of always using sprintf and passing the template into the log context so it could be used for filtering/de-duplication later.

    I’m also very happy with the JS/frontend logging. I had tried another plugin for that before, but it just logged to the standard debug.log, and obviously we both aren’t satisfied with that!

    A suggestion (and I’ll email you code how I did it) – the error logs are often too vague to be actionable, e.g. I see in this:

    > Function is_embed was called incorrectly. Conditional query tags do not work before the query is run…

    but I’ve no idea where that happened. So I catch all errors with a set_error_hander() and then force a backtrace and print that. I imagine it’s awful for performance, but I enable it for a few hours maybe once a month to make sure my error log is clean.

    I did just see a bug/bad UX in this plugin – when Auto-Refresh is enabled and I click to visit the second page I quickly get brought back to the first. I guess disable auto-refresh when a user navigates away from page 1.

    I’m going to use this for a while and dig into the code. I have a feeling this is going to be installed on every site I run!

    Plugin Author Bowo

    (@qriouslad)

    @brianhenryie great to hear that Brian!

    Feel free to email me at qriouslad at gmail. Would be awesome to be able to add backtrace info for more error types. Looking forward to see your code on that.

    Noted on auto-refresh vs pagination bug. Let me see if I can ‘fix’ that.

    Would be great to have your expert eyes looking at the code, and when you get to installing this on all your sites, please leave a nice review too. Thanks!

    • This reply was modified 2 years, 2 months ago by Bowo.
    Plugin Author Bowo

    (@qriouslad)

    @brianhenryie in v1.5.2, auto-refresh is disabled when pagination is activated / in use.

    Thread Starter Brian Henry

    (@brianhenryie)

    Warning: Trying to access array offset on value of type bool in /path/to/wp-content/plugins/debug-log-manager/bootstrap.php on line 67

    where the bool is the default false return of get_option( 'debug_log_manager' ), so this could be fixed with get_option( 'debug_log_manager', array( <DEFAULT PTIONS> )

    Plugin Author Bowo

    (@qriouslad)

    @brianhenryie I believe this has been fixed in v1.6.4. Marking this as resolved. Thanks again for reporting bugs!

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘First Impressions’ is closed to new replies.