There is no need to browse into the repositories on the main website.
It's still possible to browse there directly on the ftp servers of course,
for those that need to debug a repository install and things like that.
This is required if the queue is dropped and recreated in pgq as it
gets a new id, which needs to be used when viewing the current status
of the queue in the admin interface.
We don't link statically to it anywhere, but people can link to it from
emails or other places around the world, that sets the search engines
on it's trail.
This allows us to specify both beta and rc versions.
Requires SQL:
ALTER TABLE core_version RENAME COLUMN beta TO testing;
ALTER TABLE core_version ALTER COLUMN testing TYPE integer USING CASE WHEN testing THEN 2 ELSE 0 END;
The manifest URL (which is optional) will point to an XML file that
describes the command line, option file and environment options that
can be passed to an installer, to allow automated or non-interactive
deployment tools to figure out what info is required to run an
installer and how to pass it to it.
Requires SQL:
ALTER TABLE downloads_stackbuilderapp ADD COLUMN manifesturl character varying(500);
UPDATE downloads_stackbuilderapp SET manifesturl = '';
ALTER TABLE downloads_stackbuilderapp ALTER COLUMN manifesturl SET NOT NULL;
Instead of having to update this list manually in multiple places when
releasing new versions, just take the information out of the database
where it has to be anyway.
Fixes#90Closes#93
Also make the code automatically pick up wich PDF files exist in the
static checkout, and auto-detect their size, both A4 and US sizes. This
removes yet one more manual step, yay!
Fixes#163
This was originally not done because we had a lot of old legacy data
that didn't have entries in both tables. This is no longer the case,
and the docloads script already enforced that it couldn't happen again.
Requires SQL:
ALTER TABLE core_version ADD CONSTRAINT version_unique_tree UNIQUE(tree);
ALTER TABLE docs ADD CONSTRAINT docs_version_fkey FOREIGN KEY (version) REFERENCES core_version(tree);
This includes both the sitemap used by google and friends and our own
site index, which uses the sitemap to decide which URLs to crawl.
Fixes#171Closes#172
Previously we listed both those as unsupported, which confused some users
particularly with new beta releases. While they are technically not supported
yet, it gave off the image that specific features would not be in newer
versions anymore, since they got listed as unsupported.
In passing, fix the style of the links in case they only exist in old
versions, which would put an extra | character in the version list.
This replaces the previous ugly hack where beta versions had a negative number
as latestminor, giving a much cleaner model.
Requires SQL:
ALTER TABLE core_version ADD COLUMN beta boolean NOT NULL DEFAULT 'f';
ALTER TABLE core_version ALTER COLUMN beta DROP DEFAULT;
(Yes, we really need to move to something that can do automatic migrations)
we actually use in production, this mostly consists of the "new style" support
for raw data passthrough, but does not fix the actual problem (which is dealing
with url "double" encoding/decoding - or rather the loss of information about
that) yet...
Will fix that and sync up exactly with the production code for MW 1.19 soon...
This makes no major changes from what was there before from a pure search
perspective:
* /message-id/flat/ was already flagged with a META tag to be excluded from
indexing, since it's the same data as /message-id/.
* /list/ was already flagged with a META tag to be excluded from indexing,
since it carries no actual content, just links, and the links and descriptions
of the lists is already available under /community/ as well.
* /message-id/raw/ required a login so it produced a bunch of 401's anyway,
but this way we don't need to probe for that.
It's more efficient to block these things in robots.txt so we don't have to
spend the processing power to render a page that's not going to get indexed
anyway.
This makes it possible to pass URLs that will fail when they end up being double
escaped in some cases, since they contain non-url-safe characters. Instead, they'd
be base64-encoded, and thus safe.
Also update the django community auth provider to do just this, including encrypting
the data with the site secret key to make sure it can't be changed/injected by
tricking the user to go directly to the wrong URL.
