Widget title addition

[John-H-Smith]

Added the title to the widget on hover over url so that you can see what page it is if you have short urls enabled.

If it's the front page, the title of the website is returned.

[stklcode]

related to #78

[pfefferle]

LGTM

[2ndkauboy]

It seems that the url_to_postid() function (which is also quite heavy) does not really work for many types of URLs, such as CPT single views, CPT archives and even category archives. I'm also a bit unsure if this is a good idea in terms of a11y. 🤔

[John-H-Smith]

It seems that the url_to_postid() function (which is also quite heavy) does not really work for many types of URLs, such as CPT single views, CPT archives and even category archives. I'm also a bit unsure if this is a good idea in terms of a11y. thinking

Yeah, I thought about that and verified the behaviour with a category archieve. It seems like the function get_page_by_path could be working, but it seems to be quite buggy when switching the permalink structure, so I had switched to url_to_postid. Do you have another function which could be working too?

[MatzeKitt]

I think the cleanest way would be in storing metadata for the visited page in the Statify table, like post ID as an object ID and the object type, which could be any post type or term type. That way you can find the correct object according to object type and object ID and get the current title of the object.

[John-H-Smith]

I think the cleanest way would be in storing metadata for the visited page in the Statify table, like post ID as an object ID and the object type, which could be any post type or term type. That way you can find the correct object according to object type and object ID and get the current title of the object.

Yeah, that would be. But as of that, you would have to update the metadata every time the url or the title is updated - I think thats a quite heavy performance issue.

[MatzeKitt]

But as of that, you would have to update the metadata every time the url or the title is updated - I think thats a quite heavy performance issue.

If you construct it correctly, you can retrieve the current title of all items in the widget with a single SQL query, which is much better than using url_to_postid for every single item.

[John-H-Smith]

If you construct it correctly, you can retrieve the current title of all items in the widget with a single SQL query, which is much better than using url_to_postid for every single item.

Yeah, that's correct, it would be much better. But modifying the table after it has been created would force you to either uninstall and reinstall statify to create the table correctly or check for every website access if the new columns in the table already exist.
Also, I just noticed that the dashboard widget limits the count of all items to 100, so I am pretty sure using url_to_postid would be no problem.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[stklcode]

But modifying the table after it has been created would force you to either uninstall and reinstall statify to create the table correctly [...]

Actually that's not a big deal at all. There is already a routine to initialize the table properly, so the schema may be updated during a plugin update.

[MatzeKitt]

As addition: take a look into dbDelta

[John-H-Smith]

Alright - but with what action hook should I modify the table in your opinion? Directly in the functions file for execution on every call would be a bad practice I think...

[MatzeKitt]

I can only speak for myself, but the best way I found was to store the migration version as option and migrate the database depending on this option.

See here: https://github.com/epiphyt/embed-privacy/blob/main/inc/class-migration.php

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication