| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
- Replace hand-rolled table, filters, search, and pagination with @wordpress/dataviews for the Request Logs screen - Bundle @wordpress/dataviews and @wordpress/ui (not registered in WP 7.0-RC1) via custom DependencyExtractionWebpackPlugin config - Copy DataViews CSS into build/ and enqueue from PHP with fallback to wp-dataviews style handle when available - Filter unregistered script dependencies in Asset_Loader to prevent wp_enqueue_script notices - Expand AI_Request_Cost_Calculator from 3 providers / 25 models to 8 providers / 50+ models (adds DeepSeek, Mistral, Cohere, Groq, Grok, Ollama; adds o-series reasoning models, Claude 4.5/4.6 IDs) - Add Azure → OpenAI provider alias for cost lookup - Return $0.00 for local providers (Ollama) instead of null - Fix provider tooltip: click-to-toggle instead of hover so links are reachable - Compact operation cell to max 2 rows (code + kind inline) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Fix PHPCS array arrow alignment in cost calculator (phpcbf auto-fix) - Fix PHPStan: cast filemtime() to string for wp_enqueue_style version - Fix ESLint a11y: add role, tabIndex, onKeyDown to provider cell - Fix ESLint prettier: auto-formatted multiline expressions - Fix ESLint import: suppress no-extraneous-dependencies for webpack build-tool requires (dependency-extraction-webpack-plugin, copy-webpack-plugin) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…encies instead of React.
Codecov Report❌ Patch coverage is 72.96443% with 342 lines in your changes missing coverage. Please review. @@ Coverage Diff @@
## develop #437 +/- ##
=============================================
+ Coverage 72.24% 73.16% +0.92%
- Complexity 1162 1526 +364
=============================================
Files 68 77 +9
Lines 5609 6867 +1258
=============================================
+ Hits 4052 5024 +972
- Misses 1557 1843 +286
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry.
|
Sorry, something went wrong.
There was a problem hiding this comment.
Overall this looks decent to me but have a couple bigger questions:
Sorry, something went wrong.
| // Copy DataViews CSS into build/ so the plugin can enqueue it | ||
| // on WP versions where wp-dataviews is not a registered style. |
There was a problem hiding this comment.
If all the code changes in this file are only to support older WP versions, I think we can just remove all of this as we only support 7.0+ anyway
Sorry, something went wrong.
There was a problem hiding this comment.
It seems WP 7.0 doesn't actually register the wp-dataviews stylesheet handle. I tried removing this but the UI ended up breaking.
Is there a different handle for the wp-dataviews stylesheet I should be targeting? Left this in place for now until we figure this out.
Sorry, something went wrong.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. Co-authored-by: Jameswlepage <isotropic@git.wordpress.org> Co-authored-by: TylerB24890 <tyb@git.wordpress.org> Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org> Co-authored-by: dkotter <dkotter@git.wordpress.org> Co-authored-by: justlevine <justlevine@git.wordpress.org> Co-authored-by: gohelkunjan <gohelkunjan@git.wordpress.org> To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Sorry, something went wrong.
|
This is looking good to me. I think final thing needed here is some discussion around the introduction of a new database table in this PR. I don't have any concerns with that but others may. If we decide we're fine with that, I think final step is to ensure we are okay with the structure of the table and the data we are storing as it's harder to change that once this goes live. cc / @jeffpaul |
Sorry, something went wrong.
| $table_name = $this->get_table_name(); | ||
| $charset_collate = $wpdb->get_charset_collate(); | ||
|
|
||
| $sql = "CREATE TABLE {$table_name} ( |
There was a problem hiding this comment.
I asked for feedback on this new table and schema on our last AI call and one question was raised around the logging of cached tokens. We log input and output tokens here but not cached tokens.
Looking into it, I think this will require changes both in the PHP AI Client and within each AI Provider plugin, as right now the AI Client has a TokenUsage class that doesn't consider cached tokens.
And looking at the OpenAI Provider plugin as an example, it removes all usage information after sending it to the TokenUsage class so you can't even manually pull that information yourself.
Sorry, something went wrong.
There was a problem hiding this comment.
Hmmm, that's a good flag. I didn't really even think about cached tokens as a separate metric here. Are cached tokens returned as a value in that usage key? I think supplying them as another parameter to the GenerativeAiResult object would be the best path forward, as that already stores tokenUsage.
Given the GenerativeAiResult object doesn't currently do anything for cached tokens is that something we could add support for in like a phase 2 of this experiment or should we aim to get that squared away now?
Sorry, something went wrong.
There was a problem hiding this comment.
I didn't dive too far into it but I think upstream changes are needed to fully support this, both in the PHP AI Client and in each individual provider plugin. As such, I wouldn't put that as a blocker here
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah I reviewed a bit and that was my understanding as well 👍
Sorry, something went wrong.
|
Using WordPress 7.0-RC4, OAI provider Version 1.0.3, and the latest ZIP here I'm not seeing any data appearing in the AI Request Logs screen. |
Sorry, something went wrong.
|
Tested locally again, still nothing coming through. Tested on Playground with WordPress 7.0-RC4 running, OAI Version 1.0.3, and things worked as expected, so maybe just something off with my local. |
Sorry, something went wrong.
There was a problem hiding this comment.
May end up replacing this with the updated WPORG icon asset from #546
Sorry, something went wrong.
There was a problem hiding this comment.
Ah, yep, good catch. I can update that now that #546 has been merged
Sorry, something went wrong.
There was a problem hiding this comment.
Actually it doesn't look like that icon was even being used, it was already defaulting to the same icon we use everywhere else. I've gone ahead and removed that extra icon file
Sorry, something went wrong.
Added - Request Logging experiment that provides observability for all AI operations Co-authored-by: Jameswlepage <isotropic@git.wordpress.org> Co-authored-by: TylerB24890 <tyb@git.wordpress.org> Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org> Co-authored-by: dkotter <dkotter@git.wordpress.org> Co-authored-by: justlevine <justlevine@git.wordpress.org> Co-authored-by: gohelkunjan <gohelkunjan@git.wordpress.org>
| - tests/ | ||
| - vendor/ | ||
| - includes/Logging/Logging_Integration.php | ||
| - includes/Logging/Logging_Http_Transporter.php |
There was a problem hiding this comment.
I know I'm late here, but I'm not seeing it in the previous comments.
@TylerB24890 @dkotter Why aren't we analyzing these files?
Sorry, something went wrong.
There was a problem hiding this comment.
I believe the issue here is these files reference code coming from the AI Client and that code isn't stubbed yet, so PHPStan throws errors. And the errors thrown were internal to PHPStan so they weren't errors we could suppress individually.
I couldn't find the discussion in a quick search but the idea was we could either stub the AI Client ourselves or ignore those files until the upstream WordPress Core stubs are updated. We decided on the latter but open to revisiting that decision
Sorry, something went wrong.
There was a problem hiding this comment.
Definitely no need to revisit here, we should be able to update to the latest WordPress stubs as soon as wp-cli-stubs cuts a new release. If it's not out this week though, I'll open a PR to add in a # Reason why we're ignoring these
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Original PR: #149
What?
Adds a comprehensive AI Request Logging experiment that provides observability for all AI operations:
Closes #345.
Why?
AI operations are opaque—users have no visibility into what requests are being made, how much they cost, or whether they're succeeding. This experiment provides the observability surface needed for debugging, cost tracking, and usage analysis.
How?
Architecture uses the decorator pattern to wrap the SDK's HTTP transporter:
Use of AI Tools
Testing Instructions