Apply sentence case to all H1s in docs/en/ and remove redundant "FreshRSS"
from titles where the docs site context already implies it. Align the three
section index titles to "Administrator/Developer/User manual", matching
the existing root H1 "FreshRSS manual (English)".
Add missing H1s to two pages that were silently dropped from the sidebar:
the user FAQ and the Caddy reverse proxy page. The sidebar template uses
page.title (derived from H1 by jekyll-titles-from-headings), so pages
without an H1 had title=nil and were skipped.
Update sidebar parent labels in docs_nav.html and the chapter list in
en/index.md to use the new "* manual" naming. Update link text in section
indexes that referenced the old H1s. Bundle two grammar fixes encountered
along the way: "an User Interface" -> "a user interface", and drop the
awkward "the" in "Configuring the email address validation".
EN only. No filenames, URLs, or anchor targets changed (anchors come from
H2 and below, which are untouched). FR is generated from EN via po4a and
will be regenerated separately.
Co-authored-by: Bjørn A. Andersen <polybjorn@users.noreply.github.com>
* docs: Fix broken or dead links
Used the following commands to find broken links:
1. `lychee -E --dump https://freshrss.github.io/FreshRSS/en/ --include freshrss.github.io --output links.txt`
2. `lychee -v --suggest --archive wayback --timeout 5 -u "Mozilla/5.0 (X11; Linux x86_64; rv:148.0) Gecko/20100101 Firefox/148.0" --files-from links.txt --output output.txt`
3. `cat output.txt`
Then did the same for https://freshrss.github.io/FreshRSS/fr/
We could look into using lychee in CI:
https://github.com/lycheeverse/lychee?tab=readme-ov-file#github-action-usage
* Replace PostgreSQL 16 link with current version
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
* Remove paragraph about bug message format
* Update README with official app website links
* Replace broken French images with English versions
* Fix broken Fever API docs link in French docs
* Replace GNU Social link with new one in `shares.php`
---------
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
Before, we had 5 classes in the ModelPdo file. It was bad for 2 reasons.
The first reason is that it is considered bad practice to have multiple
class in one file. This is especially true when using autoloading. On top
of that it is less readable considering the size of the file. The second
reason is that so far we were lucky. Everytime we needed to access the
database, it was through the ModelPdo class which loads all the other
classes. If we want to access directly the connection, it wont be loaded.
On top of that, the system is configured to work on a single database,
but as we have every connection definition in a single file, all classes
were loaded at the same time. Thus using memory and processing time for
nothing.
Now, we have a file for each class. To work with autoloading, classes
were slightly renamed to match autoloading rules.
Before, we had 5 classes in the ModelPdo file. It was bad for 2 reasons.
The first reason is that it is considered bad practice to have multiple
class in one file. This is especially true when using autoloading. On top
of that it is less readable considering the size of the file. The second
reason is that so far we were lucky. Everytime we needed to access the
database, it was through the ModelPdo class which loads all the other
classes. If we want to access directly the connection, it wont be loaded.
On top of that, the system is configured to work on a single database,
but as we have every connection definition in a single file, all classes
were loaded at the same time. Thus using memory and processing time for
nothing.
Now, we have a file for each class. To work with autoloading, classes
were slightly renamed to match autoloading rules.
* Add a Minz_Migrator class
Until now, we updated the database structure somewhere in the code but
it wasn't always consistent and somehow complicated to find. Also, this
code was always checked for nothing.
The Migrator aims to improve and ease the creation of migrations. It
should improve the way we apply the updates, making the update server
almost useless.
References:
- example of migration (before Migrator): cc0db9af4f (diff-11a53443fa81512b128c66b065df0679R10)
- update server: https://github.com/FreshRSS/update.freshrss.org
- PR moving the code of the update server to the core: https://github.com/FreshRSS/FreshRSS/pull/1760
* Automatically apply migrations
For now, administrators are used to have nothing to do during an update
else than getting the new code. I suggest to keep this behaviour and
automatically apply migrations if we detect new ones.
Another solution would be to create a CLI command and ask admins to call
it after getting the new code. It could hide migrations errors to end
users, but admin can forget to apply migrations since there are not used
to it.
* Add documentation for Minz Migrator
* Execute migrations even if next ones are applied
* Change mechanism to prevent multiple update at once
* Use mkdir to create the lock and to test it exists
Reference: https://stackoverflow.com/a/731634
* Append .lock to applied_migrations_path
There are no needs to define another file to serve as a lock.
* Change migrations naming convention
* Apply suggestions from code review
Co-Authored-By: Alexandre Alapetite <alexandre@alapetite.fr>
* Perform a low-cost migration versions comparaison
* Clarify version numbers concerning the migration system
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
