HelloZeroNet / HelloZeroNet/ZeroNet
invalid config on update of website
- Langage dominant
- JavaScript
- Étoiles
- 18.8k
- Forks
- 2.3k
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
line 231: config.py should NOT assume that sites without a content.json(which may being updated by owner- and need a re-scan) should be of a certain size- namely 10mb.
This may apply for new sites, but not existing ones. You cant change site data within the browser(cant point to webzite-not in owned list) if the content.json is being updated. Its as if zite doesnt exist, which is wrong.
10mb may not even be sane at this point- I need 65mb for my updated content. I took me a good min to track the setting down- which should be in the master config file, not across 5 python files. simply removing old content (files) doesnt work, they are still referenced(and hosted elsewhere)
The easier fix is to cull the site verify code in the file manager processor- but thats not the correct way of addressing the problem. That is sidestepping it.
most users will push updates and sync over and over- but in event of removal of data by owner- the content.json MUST be updated--and this is the only way to do it. Hack in the "changes for .bit domains and optional content" by yourself AFTER the json is recreated for the "loss of content".
why would u do this- several reasons.
1-save space
2-(my case) host content elsewhere
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Piste de recherche
Start at line 231 of config.py and trace how the 10MB assumption is used by the file manager processor when content.json is missing or being regenerated. Review the related configuration across the mentioned Python files and the content.json update path. Done means existing sites can be rescanned after content removal or external hosting without being treated as nonexistent or rejected solely by the default size limit.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- python
- Domaine
- backend
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 25/100