Thanks, it works as expected. I merge the branch.
Thank you, guys. Great work. I merge the issue.
Hello Mortona:
Thank you very much for your collaboration. Yes, it is a good idea to show a statistic about the field usage.
We will include that information.
It works as expected. I merge the fix.
I’ve only made one modification, which is extracting the logic that calculates the language prefix from the target object to the Repository service, as it’s also needed during the processing of redirects.
Could you please take a look and do a quick QA? Thanks!
It works as expected. I merge the branch.
Thanks you very much Edu, fix merged.
We have added the possibility to download the report of block layout to be more useful for the user.
I have refactored the code to show the summary in a table:
This is different from the original proposal, but I realized that this format is clearer for the user.
I merge the branch.
Hello Sirclickalot:
Thank you very much for your feedback. We will fix the issue as soon as possible to ensure compatibility with sites that are not multilingual.
Best regards.
Merged funcionality.
Thank you Antonio and Sady for your colaboration.
Merge the branch. Thank you very much Antonio y Sady.
The types errors has been fixed and I used the service "router.route_provider" to get information the configuration of the views using their machine name. This information includes the path and if it is an admin route.
Maybe is a better way to this info.
I marge with the main branch. Thank you Sady for your feedback.
Added information about the access configuration of views to the Views report, along with a column indicating whether anonymous users can access each view. If it is an administrative view, the value will be displayed in red.
An insight has been included to alert about such cases.
A configuration object has been created, which can only be modified in the corresponding YAML configuration file, to include those views that, despite being on the administrative path, are configured to be potentially accessible to anonymous users.
Ready for testing.
Additional checks have been added to ensure that the function _redirect_delete_helper__set_key_value_data() receives the correct values. There was a case where an error was generated due to passing a NULL value when a node search was performed to create the redirect, but the node was subsequently deleted, leaving the field empty.
Issue fixed.
Report implement and tested. I merge funcionality.
It works as expected. Thank you very much Antonio for your contribution.
Hello thomwilhelm. Thanks a lot for your fix. I merge for the next release.
Implemented the report that provide information about the Database.
- Database size
- Number of tables
- List of the largest tables (20)
- List with all the tables (rows, data length, Index length, Total size)
@edu Great job! I just refactored the code that determines if an Insight is active or not to ensure compatibility with the form alterations.
Yes, I am I agree with @gedur. One of the contexts in which Xray is very useful is in legacy or highly outdated projects; in fact, we encountered one of these issues a few weeks ago.
There are many views generated by modules that are not cached because they are used to administer the site.
We are unable to exclude all of them by default since any module can create this type of view.
The best solution is to create a functionality that allows us to configure which views we want to exclude from the insights.
I change the title of the issue to implement this functionality.
Hello sourav_paul
Thank you very much for your contribution. If you do not mind I have modified it lightly.
The message about enable the module Views UI is showed as a Drupal message to avoid repeat the same message in every row:
Best regards.
I think this request is very tied to the Search API Solr module, which is the context in which it's required that the view not be cached. Applying this kind of differentiation might contradict the purpose of the insight and the warnings we issue in it. In other words, it's ultimately a heads-up that there may be something that needs to be reviewed.
I’ll leave the issue open in case anyone else thinks it's necessary to make this distinction, especially from a usability perspective.
There is a logic to exclude submodules by checking the project set in the info.yml, which does not seem to be effective in the case of the Facets module, where the project parameter is not set.
For example, if Webform is used in the project, the disabled submodules are not displayed.
It is necessary to review the logic to make it much more refined.
Hello:
I have found two main problems in the patch:
- In a Drupal 9.5 I would be able to install the patch, but the four cancel options are still shown.
- In a Drupal 10.3 I have problems with the patch application due the function user_requirements are instanced twice.
Added the "currentRevision" to the first query to unify.
Hello @kcolwell,
I am trying to replicate the results you have shown, but I am unable to do so.
Both queries are quite simple.
The first one:
$query->accessCheck(FALSE)
->condition('status', '1')
->groupBy('type')
->aggregate('nid', 'count', NULL, $alias_count)
->execute();
This query counts all the published nodes grouped by type.
The second one:
$query->accessCheck(FALSE)
->currentRevision()
->aggregate('nid', 'COUNT', NULL, $alias)
->groupBy('langcode')
->groupBy('type')
->sort('type')
->sort('langcode')
->execute();
This query does the same but grouped by type and language.
The only fundamental difference between the two queries is the use of currentRevision().
There are two possibilities:
- The currentRevision() method is needed in the first query to avoid counting all revisions, but I am not sure about that.
- There are 81 active languages on the site.
I am going to add the currentRevision() flag to the first query for consistency.
However, how many translations does each node have?
Thank you very much.
lpeidro → changed the visibility of the branch image_styles_generator-3474990 to hidden.
Improvements already merged.
Fix merged.
I took the opportunity in this issue to add an improvement to the Xray Audit Insights code. Previously, when a new insight was introduced, the settings form had to be refactored. With this improvement, that is no longer necessary; the form now automatically manages the existing insights.
I am merging the issue and considering it closed. Thank you both very much for your collaboration.
- The first column of the report, when it exists, should be the ID or machine name column.
- In the menu report, when it exists, the main menu should be loaded by default.
- Remove the 'lang' column from the roles report.
- In the modules report, the header for the 'Types' column is missing.
- In the themes report, the machine names column should be placed first.
- In the CSV of the menus, the word 'array' is printed in the cells corresponding to arrays.
- In the user report grouped by role, also show the roles that do not have any associated users
Fixed issues detected during MR review and merge.
Fixed issues detected by Sady and merge funcionality.
Status
First approach completed.
It has been implemented for the case of nodes. However, it would be advisable to implement a batch process since these queries might take some time. In the end, we performed an accounting of the usage of all fields.
It might be worthwhile to create another report from the perspective of the storage
Improvements implemented:
- Implemented a Drupal service named "xray_audit.cache_manager" to manage the custom cache bin created for Xray Audit.
- Implemented a button in the main page of the module to be able to flush the Xray Audit Cache.
- Implemented cache for all content metric reports, and are invalidated using cache tags. So when a new modification happens in the content entities, the cache is invalid.
- Implemented cache for module reports with a temporal limit of one hour.
It is ready for QA.
We have added configuration form for the Xray Audit Insights module. It is ready for QA.
We have included a video showing the functionality.