Track internal search queries

[florianbrinkmann]

This PR:

• ensures search queries are stored in the DB (lowercased, and never with a trailing slash)
• Adds a Statify_Dashboard::parse_target() method that is called for the targets list in the widget. It makes sure the search query items are not just displayed as /?s=[…]

Looks like this:

Closes #220

[Zodiac1978]

Have you discussed about creating an own section for this instead of adding this data to the "views" section?

[stklcode]

I didn't (maybe other parts of the team did). But a dedicated section seems like a good idea and might integrate well into the planned extended evaluation features. Should be removed from the pages view then or maybe just grouped together as "Search".

[florianbrinkmann]

Didn’t think about adding an own section, but like the idea, then we also do not need the Search query: prefix

[florianbrinkmann]

Changed it so that the search queries are displayd in its own list

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication

[2ndkauboy]

Is this common to add a "changelog" like this to PHPDoc? And now we also have three @since and no @version anymore. 🤔

[florianbrinkmann]

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)

[stklcode]

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:

@since 1.0 introduced (if this is left empty, the natural assumption would be the same)
@since 1.1 return boolean result instead of void
@since 1.2 make parameter $foo optional with default 42

@version 1.1

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

[2ndkauboy]

"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?

[stklcode]

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.

[2ndkauboy]

Do I get this right, that you first create a table with empty <tr> tags and then fill/replace them using JavaScript? Why not generate the <table> in JavaScript instead?

[2ndkauboy]

OK, you do just the same as with the other tables 🙈