-
-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Track internal search queries #242
Open
florianbrinkmann
wants to merge
15
commits into
develop
Choose a base branch
from
220-track-internal-search-queries
base: develop
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 12 commits
Commits
Show all changes
15 commits
Select commit
Hold shift + click to select a range
66e28c3
Track internal search queries
florianbrinkmann f07175a
Better inline docs
florianbrinkmann 6e17f40
Add escape function to dashboard output again
florianbrinkmann 55d1a99
Merge branch 'develop' into 220-track-internal-search-queries
stklcode d83f4c1
Modifications from review suggestions
florianbrinkmann a03fba1
Check for additional query params on search queries and remove them
florianbrinkmann a75a9e1
Add section for search queries
florianbrinkmann dcb6d8b
Use SQL wildcards for SQL like
florianbrinkmann b32e817
Update @since version
florianbrinkmann ebfba0e
Docs
florianbrinkmann 5861540
Split SQL queries in multiple lines
florianbrinkmann 88b1a82
Fix merge conflict
florianbrinkmann 288541f
Switch searches display to JS
florianbrinkmann 8837493
Fix refresh button styling
florianbrinkmann 19208f0
Fix PHP CS things
florianbrinkmann File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this common to add a "changelog" like this to PHPDoc? And now we also have three
@since
and no@version
anymore. 🤔There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we used the
@version
wrong, if I am right, it is ment to set versions for APIs and similar (https://docs.phpdoc.org/guide/references/phpdoc/tags/version.html#version), and you can use multiple@since
(https://docs.phpdoc.org/guide/references/phpdoc/tags/since.html#since)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep,
@since
is commonly used for changelog purposes, mostly changes to method signature or high-level behavior (at least helpful on public API that can be quite helpful to have this information on hand in the IDE)@version
is meant for semantic changes and the state of the functionality.Multiple of either one don’t make much sense, because they yield barely any information, just “something was done here“.
Something like this would be more or less meaningful:
I personally often omit the version tags, if there is no real need for that. The since-tags often help even in the same project to see why a method is used in a non-optimal way or similar. In such cases the hint “method was updated in 1.2“ and “we use it since 1.1“ immediately presents a valid reason, so we don’t have to guess what someone may have thought here.
Btw. that is also done in WP core and the changelogs are rendered in the reference articles, e.g.: https://developer.wordpress.org/reference/functions/wp_parse_url/#changelog
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Since" we only use it on some functions and we don't even have a real "public API", would we even mind keeping these
@since
version numbers up to date?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, a public method is a public method and there are some recommendations out there for things like workarounds or custom triggers that call some of these. Some snippets given by ourselves in the support forums. Documenting API changes enables users of those to potentially migrate their logic without opening another support request, if changes are not self-explaining.
I agree, the majority of our code is designed for internal use and only exposed public for hooks etc.
But as with every project, that’s yet another part of documentation that might get out of sync over time. Though it’s probably one of the easier parts, as old annotations typically never become wrong, so we only have to append another one-liner, if necessary.