We want an API for this so they end up in the queue with all the other
requests, and get delivered to all our frontends without needing each node
to know about which frontends exist.
Now that we have more metadata, we can render this on the main page instead of
on the wiki. This commit copies all the text from the current wiki page, and
uses the new fields in the Version model to render the table on the same URL
as the reference was on before.
Previously this had to be rsynced outside of the website. By allowing the
upload here, and automatically purging the data from varnish, we will reach
"almost instant" updates of the ftp site structure on the web.
This makes it possible to render the search results on the main engine.
We still run the query on the seprate search server, so once has to be
configured in settings_local.py with the key SEARCH_DSN (standard
PostgreSQL/psycopg2 connection string)
This allows all models inherited from PgModel to specify which
URLs to purge by either setting a field or defining a function
called purge_urls, at which point they will be purged whenever
the save signal is fired.
Also implements a form under /admin/purge/ that allows for manual
purging. This should probably be extended in the future to show
the status of the pgq slaves, but that will come later.
Includes a SQL function that posts the expires to a pgq queue. For
a local deployment, this can be replaced with a simple void function
to turn off varnish purging.
Each module now contains a struct.py file that will return all
the URLs that it can generate (yes, this is a small break of the
abstraction of url.py, but we've broken that elsewhere as well),
and also which search-engine-weight (0.1-1.0) that this URL should
be given.
the fact that when pages are served through Varnish, the request will come
from the Varnish server and not from the client.
Create a /system_information page that shows some information about the
connection to help diagnose how the caches work.
of the RSS feed. (Which will receive a new URL now that it lives in the
actual app and not in with the static files, so a redirect will be needed
there).
part of the core, since it seems like it could be useful for other
kinds of objects as well in the future, but for now only the
software catalogue uses it.
