Feat/add grav

[rafspiny]

Scripts which are clearly AI generated and not further revised by the Author of this PR (in terms of Coding Standards and Script Layout) may be closed without review.

✍️ Description

🔗 Related PR / Issue

Link: #

✅ Prerequisites (X in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No breaking changes – Existing functionality remains intact.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

---

🏗️ arm64 Support (X in brackets)

• arm64 supported - Tested and supported on arm64.
• arm64 not tested - Assumed to work on arm64, but testing has not been done.
• arm64 not supported - Confirmed upstream dependencies or binaries do not support arm64.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to website-related JSON files or metadata.
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

---

🔍 Code & Security Review (X in brackets)

• Follows Code_Audit.md & CONTRIBUTING.md guidelines
• Uses correct script structure (AppName.sh, AppName-install.sh, AppName.json)
• No hardcoded credentials

📋 Additional Information (optional)

I could not test the upgrade part, with the creation of the backup. It should hopefully also address community-scripts/ProxmoxVE#2124 later on, if it makes it to production.

This is adding the Grav CMS, better known as Grav

📦 Application Requirements (for new scripts)

⚠️ Do not remove this section.
It is used by automated PR validation checks.
If this PR is not a new script submission, leave the checkboxes unchecked.

Required for 🆕 New script submissions.
Pull requests that do not meet these requirements may be closed without review.

• The application is at least 6 months old
• The application is actively maintained
• The application has 600+ GitHub stars
• Official release tarballs are published
• I understand that not all scripts will be accepted due to various reasons and criteria by the community-scripts ORG

🌐 Source

[rafspiny]

Hi @MickLesk and thanks for the review.
I made the changes:

• Removed all comments
• Shifted to use the fetch_and_deploy_gh_release function
• Use grav instead of ${APPLICATION} in the places you indicated
• Remove the else branch for update check

[CrazyWolf13]

also please mark resolved conversations as resolved, thanks.

[MickLesk]

Rest Look ok for me

[tremor021]

this is not restored after backup?

[rafspiny]

Is null a valid value? I would rather have null if this field is just informative. I understood that it is not used anywhere.

[MickLesk]

Tremor mean in CT/Grav.sh it will be erased and never backuped

[rafspiny]

I was just rethinking that part. Grav has its own backup/restore mechanism and also upgrade from within the application. That is the recommended way of upgrading it and it works very well. If I simply restore the backup zip after replacing the /opt/grav, the website may not work at all.

Is it acceptable to just create the backup file or disable update at all?

[MickLesk]

Then you need to remove the clean_install in CT and Show an hint with msg_custom (Look other Scripts), that use the build in updater

[rafspiny]

So,

1. create the backup file
2. update the pat (/opt/grav)
3. print a message to help restoring the backup?

Anyhow, I am gonna try to install an older version in the installer instead of latest, and then try to update

[rafspiny]

Actually, I just tested the update command after hardcoding an older version.
Just removing CLEAN_INSTALL was enough. The website was preserved, with the pages, plugins and themes created/selected before the update. I am undoing that commit now.

To get back to the original point. I think I can leave the config_file as it is, or place null.
I just removed the CLEAN_INSTALL . @tremor021 @MickLesk

[MickLesk]

If you remove the Clean Install and the project Maintainer Clean some npm/PHP/Go or something files in next updates it Break because the files stay in the folder and conflicted with newer Files. Thats the reason for Clean Install. Just Backup before, then Clean Install, then move Back after Clean install

[rafspiny]

I have concerns about middling with the folders of the project after an upgrade. I would rather remove the fetch_and_deploy from the update script and use the recommended upgrade.
bin/gpm self-upgrade -y from https://learn.getgrav.org/17/cli-console/grav-cli-gpm#update

I am gonna try with another commit, but I think this is the safest way to go.

[rafspiny]

I tested with self-upgrade. I could update from 1.7.51 to 1.7.52 with the update command inside the LXC container. I kept my website and plugins/themes.

The process provided by Grav itself, ensure also that dependencies are not broken and that if something will break, it will get disabled. That's a great advantage of this approach compared to just moving back things after installing a new version with CLEAN_INSTALL=1. I think this is the best approach to update the container software.

How does it look for you @MickLesk ?