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.
Status:
The plugin has been defined, and the system for implementing insights has been established.
Two insights have been implemented:
- one that detects content entity bundles with no content, and
- another that detects custom modules that are not enabled and may therefore be candidates for removal.
I think we can merge this issue when it is ready. If we need to add new insights, we can implement them in a new issue.
Ready for testing.
The system for generating automatic routes based on plugin definitions has been modified.
Previously, there was a route with two parameters. The corresponding page or report was constructed using these parameters.
Now, a specific route is automatically created for each operation defined in a task plugin.
This approach is believed to be more consistent and correct for creating these routes.
Constructing them this way allows us to define local tasks for the operations of a task plugin.
By adding the parameter "local_task: 1" in the plugin definition, local tasks will be automatically defined from the plugin's operations, generating a tab menu in this case.
Therefore, this significantly improves the structure and navigation for the user, without altering one of the module's principles, namely the quick and easy implementation of new reports in the module.
It is ready for QA.
The problem is not the release.
It is a temporary bug that occurs when the module is uninstalled and then reinstalled.
The temporary table where the data is stored is removed, but not the state value that determines when to update the data in the table. As a result, the table remains empty until the state value is outdated.
The solution is to remove this value when the module is uninstalled.
It is ready to test.
I am working in this issue to generate a patch as soon as posible.
lpeidro → created an issue.
Thanks Sady.
If there is no configuration exported, get them from database. In this case, the modules actives in the site will show as actives by core.extension although, they have actually been activated by a config split.
In multi sites the configuration files are more reliable. Therefore, it is recommended to generate this report on sites where the configuration has been exported.
@sady, it is ready to test,
Merged the 1.x branch and fix phpstan errors.
Merging the branch.
Thank you very much abhishek_gupta1 and clemorphy.
Merged the 1.x branch, resolved the conflicts, tested the functionality, and it works correctly.
Merging the branch, thank you very much, Sady.
I have taken advantage of this task to correct the errors detected in the static analysis of GitLab.
Thank very much, Sady, It works properly.
This functionality have been implemented in other issues.
There is a service to implement the download button easily in any report, so close this issue.
It would be great to add two improvements to this report:
- The first: include the link to the menu item's form in case it needs to be edited.
- The second: for those menu links that do not reference an entity but a route, add information about the route, such as the route name.