Closed bbertucc closed 1 year ago
I completely agree with this direction. Leverage the existing solutions for scanning.
I found https://github.com/bbertucc/equalify/issues/142, but I don't think that is what I'm looking for.
I would like to be able to display a sub-set of issues within Drupal.
When it comes to managing issues, we've found the easiest way to make users aware of issues and make the necessary changes is to present the information in the system where the content is being managed. In our case, the Drupal editing experience.
Think about link checking or Outlook reminders if you say "see attachment", but the email has no attachments.
We do not want a full-blown "content governance"/CYA solution.
The Site/Report model gives us the ability to create a list of issues and vet the issues between things content managers working primarily in the WYSIWYG, but can't expect Site Owners or Abitious Site Builders to log into an Equalify instance to get this information.
If Equalify can provide a JSON version of a report, we can write a Drupal module to display that report within each Drupal instance.
If Equalify can provide a JSON version of a report, we can write a Drupal module to display that report within each Drupal instance.
Would an API also solve that problem? Opened #193
Not sure I'm following about #195 relates. A true, API first approach where the Equalify UI becomes a decouple application is overkill for our needs and would make customizing the site inventory features of this project more complicated. We just want the same values that are currently a mix of HTML and content being rendered from index.php and views/reports.php to be available as JSON.
I'm thinking of something simple like https://github.com/bbertucc/equalify/pull/196
I'm thinking of something simple like https://github.com/bbertucc/equalify/pull/196
Great! Love it. Merged.
Closing this issue in favor of #198
Equalify needs to focus on managing issues. The added focus will help us better serve users.