gitguardian[bot]
commented
3 months ago ⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.
Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.
🔎 Detected hardcoded secret in your pull request
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | | | -------------- | ------------------ | ------------------------------ | ---------------- | --------------- | -------------------- | | [263288](https://dashboard.gitguardian.com/workspace/56355/incidents/263288?occurrence=157829778) | Triggered | Generic High Entropy Secret | 71e62f656799ec67431d1235553f7304e879d3f4 | .env | [View secret](https://github.com/jasperweyne/helpless-kiwi/commit/71e62f656799ec67431d1235553f7304e879d3f4#diff-e9cbb0224c4a3d23a6019ba557e0cd568c1ad5e1582ff1e335fb7d99b7a1055dL19) |
🛠 Guidelines to remediate hardcoded secrets
1. Understand the implications of revoking this secret by investigating where it is used in your code. 2. Replace and store your secret safely. [Learn here](https://blog.gitguardian.com/secrets-api-management?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) the best practices. 3. Revoke and [rotate this secret](https://docs.gitguardian.com/secrets-detection/secrets-detection-engine/detectors/generics/generic_high_entropy_secret#revoke-the-secret?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment). 4. If possible, [rewrite git history](https://blog.gitguardian.com/rewriting-git-history-cheatsheet?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment). Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data. To avoid such incidents in the future consider - following these [best practices](https://blog.gitguardian.com/secrets-api-management/?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) for managing and storing secrets including API keys and other credentials - install [secret detection on pre-commit](https://docs.gitguardian.com/ggshield-docs/integrations/git-hooks/pre-commit?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
sonarcloud[bot]
This PR intends to replace our SCSS code with Tailwind CSS. The original motivation was that, when I tried to add extra buttons on activity pages in the front office (waitlist, contact, etc), I noticed that all forms had set their width to 100%. Because of this, it wasn't easily possible to put multiple form buttons next to each other without thoroughly reworking this property. Moreover, looking back at the SCSS, it was clear that fixes were added upon fixes to make everything work. This motivated me to take a step back and look at what would be a better way to approach these issues.
Looking at where frontend code for the web has moved, it's clear that the PHP way of templating the whole page isn't where everyone is moving. Instead, small composable components with their structure, styles and behavior colocated in the form of CSS-in-JS and DOM manupulation seems to be the movement with frameworks like React, Vue, Angular, Svelte and many more. Looking at the PHP ecosystem, a similar framework isn't available (or even applicable for the use case of server side rendering). However, at the very least colocating styles and structure felt doable and like a step forwards.
Currently, the structure of the pages is located in
templates/while style definitions are located inassets/style/. Comparing these folders, they are structured quite differently; colocation has not been a concern. To that end, I tried to look for ways to incorporate CSS within Twig templates, without resorting to adding style attributes everywhere, as those don't support things like pseudo-selectors. The most logical solution seemed to be Tailwind CSS; the only other easily available option seems to be theinline_cssTwig filter, however this suffers from the same issue as adding style attributes everywhere and doesn't support running it on fragments.The idea of this PR is to explore the use of Tailwind instead of SCSS. To that end, the intention is to completely remove all SCSS within this branch, to see whether we can simplify our build process.