* New extension hook entry_auto_read
For extensions to be notified of articles being automatically marked as read for various reasons
* Documentation + entry_auto_unread
* XML+XPath
#fix https://github.com/FreshRSS/FreshRSS/issues/5075
Implementation allowing to take an XML document as input using an XML parser (instead of an HTML parser for HTML+XPath)
* Remove noise from another PR
* Better MIME for XML
* And add glob *.xml for cache cleaning
* Minor syntax
* Add glob json for clean cache
* Easier full-text search possibility
Contributes to https://github.com/FreshRSS/FreshRSS/issues/1331
Avoid concats in searches to make text indexes easier to build
* Fix tests
* Documentation
* Use typographic quotes
* A few fixes
* Fix
* Fix not saved
* Implement feedback
* Detail
* Revert spoken English fixes
Left for a future dedicated discussion
* More reverts
* Final reverts
* Final minor
* Improved markdownlint
* Relaxed rules slighlty
* `npm run markdownlint` for automatic tests
* `npm run markdownlint_fix` for automatic syntax fixing
* Applied the fixes on all our Markdown files
Before, only the user configuration was supported by extensions. But it was
limiting if one has to create a system extension with configuration.
Now, both user and system configuration are supported.
* adding self CREDITS.md
* add "theme" to link for easier navigation
* add documentation about themes and the files that go in them
* add admin documentation for themes
* fix markdown styling
* fix CSSJanus usage
Before, the extension configuration was handled by its author. There
was discrepancies between extensions on how the configuration was
stored.
Now, we could rely on a single way of storing configuration. This won't
invalidate how the extensions are storing their configuration but will
allow authors to focus on what is important.
* remove outdated mailing list information
* add information about normal view
* add information about global and reader view
* fix import section header
* reorder documentation to reflect menu's order
* clarify setting as default in normal view
* add info about reading section for config
* fix heading levels, add info about archive + profile sections
* unfix heading levels
* move section on feed-specific settings to the subscription management page
* update information about adding feeds, add information about feed management
* fix link to security page in installation
* fix broken links
* fix broken link to install page
* add lighttpd from project readme
* add php modules to step 4, add horizontal line to better separate steps from footnotes visually
* fix broken link
* add index page for easier access of other pages
* move first steps document
* make dedicated bug reporting page
* make index page for linking to other pages
* moved fever API to relevant location, linked to index
* remove outdated mailing list information
* add information about normal view
* add information about global and reader view
* fix import section header
* reorder documentation to reflect menu's order
* clarify setting as default in normal view
* add info about reading section for config
* fix heading levels, add info about archive + profile sections
* unfix heading levels
* move section on feed-specific settings to the subscription management page
* update information about adding feeds, add information about feed management
* fix link to security page in installation
* fix broken links
* fix broken link to install page
* add lighttpd from project readme
* add php modules to step 4, add horizontal line to better separate steps from footnotes visually
* fix broken link
* add index page for easier access of other pages
* move first steps document
* make dedicated bug reporting page
* make index page for linking to other pages
* moved fever API to relevant location, linked to index
* re-fix link
* remove mention of defunct mailing list
* grammar fix
* replace stream with feed
* add optional items, replace stream with feed
* replace stream with feed
* fix word choice
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
* fix word choice
better reflect age of project
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
* grammar fixes
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
* remove double headings
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
* change single quote to double quote for consistency
* add subreddit link
* change php module list to Dockerfile link
* fix link to developer index, change html links to md for consistency
* update css selector terms
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
When an extension defines an `autoload` method, it will be registered
automatically before enabling the extension.
For the extension creator, it's easier because there is no need to
register it manually.
* add two new hooks
I develop a new extension and i need 2 new hooks for it
* update EN documentation
* Correct typing errors
* Update app/views/helpers/javascript_vars.phtml
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>
By default, the container starts without extensions. But if for some reasons,
you need to add them without copying or moving some code, you can embed them
while starting the container. The syntax is:
```
make start extensions="/full/path/to/extension/1 /full/path/to/extension/2"
```