http://status.net/open-source/issues/2442
Notes:
* Mapstraction causes JavaScript errors in XHTML mode, breaking our code if we're run later so the link doesn't work to get back to Desktop.
* not 100% sure how safe feature detection is here?
* Currently will be useless but visible links if no JS available; need to fall back to server-side for limited browsers
There's a new menu layout in this version of the software. It was
implemented as a plugin in 0.9.x to avoid clashes with existing themes,
but we're going to break that compatibility in this version, so we're just going for it.
This change involved moving all the changes in NewMenuPlugin into the
default code that was calling it. In addition, since
accountsettingsaction and connectsettingsaction differed only by menu,
I removed them, changed all references to them to the settingsmenu, and moved
the combined nav to its own class.
Let's put that episode behind us.
The CSS shim that was loaded by NewMenuPlugin for certain themes and certain actions
was removed.
StatusNet core code now sets the tooltip text on .attachment.more links when they receive their attachment-expansion magic; this will override the hardcoded tooltip text saved from OStatus plugin when displaying timelines in the web UI.
* moved some translator comments that were not directly above the line with the message to the correct location.
* i18n for UI text.
* superfluous whitespace removed.
I've consolidated the checks for which user to use for single-user mode into User::singleUser(), which now uses the configured nickname by preference, falling back to the site owner if it's unset.
This is now called consistently from the places that needed to use the primary user's nickname in routing setup.
Setting $config['singleuser']['nickname'] should now work again as expected.
* now ignoring if-modified-since if we failed an etag if-none-match comparison, per spec
* now including a hash of user id/nickname in most etags, so we'll update the view properly after login/logout
For API methods, checking the API-auth'ed user. (Many change results to include things like 'you're subscribed to this user' or 'this is one of your favorites', so user info is again needed)
There'll still be some last-modified stamps that aren't including user info properly, probably.
Currently only one custom theme may be uploaded per site, saved with the name 'custom' and stored into the local/themes subdirectory.
Administrators can upload a .ZIP archive containing a theme through the design admin panel; its contents are validated to ensure that only legit files are saved, and a 5M size quota is enforced.
Theme upload requires the zip extension for PHP; if not present, theme uploading is disabled by default.
Uploading and the custom CSS can be controlled via $config['theme_upload']['enabled'] and $config['custom_css']['enabled'].
Configurable directory/path/server for 'local' subdirectory (currently only as used for themes; local plugins not yet switched over)
Can set $config['local']['dir'] etc; not currently exposed in the admin panels.
Per-site directories on a separate themes server could be set up such as:
$config['local']['dir'] = '/path/to/themes/local/' . $_nickname;
$config['local']['server'] = 'themes.example.com';
$config['local']['path'] = '/local/' . $_nickname;
$config['local']['ssl'] = 'never';
* added a few XXX (that's StatusNet for FIXME, right?)
** proposing de-duplication of a message appearing ~50 times
** marking bad pagination implementation
* moved the TRANS: comments in action.php down to exactly before the line in which the message appears. Otherwise gettext does not put them in the pot file
* fixed a XXX in action.php removing double spaces
The final whitespace should be dropped from the source messages after we've stabilized; trailing space is pretty unreliable to keep through translation tools and should be avoided. Use separator strings outside the messages!
All 'connect' menu panels used to be optional, so Action tried to
figure out what the first item on the 'connect' menu should be.
This is no longer necessary because we have the non-optional OAuth
client connections panel now, which is not optional and can't be
turned off.
We have about 10-12 JavaScript pages per Web page. They usually
are based on the same server as the Web pages, but since they're
static files, it makes sense to offload them to a lite server that
handles static files well.
This commit lets you set a separate Javascript server and path for the
default Javascript code in StatusNet.
Squashed commit of the following:
commit 139d1622fdafe5ad00c820224416d9021efc3234
Author: Evan Prodromou <evan@status.net>
Date: Wed Jan 27 11:30:24 2010 -0500
modules that call htmloutputter::script() don't prescribe js/ path
commit c6ca3174af73efed55eaed5ff1e2a3bdc77d2d87
Author: Evan Prodromou <evan@status.net>
Date: Wed Jan 27 11:28:07 2010 -0500
configurable server and path for javascript files
New configuration options to define a single-user mode. This hides
most of the "community" pages, like the public timeline and groups.
The main user's timeline becomes the main page, and most other URLs
are changed.
Switching back and forth between 1-user and multi-user mode is
probably hazardous.
Squashed commit of the following:
commit d814aa5c92d14a27a12baba7893f3f8bf63f1d08
Author: Evan Prodromou <evan@status.net>
Date: Tue Jan 26 00:17:27 2010 -0500
don't show inbox and outbox in single-user mode
commit 47f19b9523a7015d4c6e460b73ea32c839e00aa1
Author: Evan Prodromou <evan@status.net>
Date: Tue Jan 26 00:15:22 2010 -0500
show correct URL for logo in single-user mode
commit 552010cffc33eadbc512ec5a67619dbc2015239a
Author: Evan Prodromou <evan@status.net>
Date: Tue Jan 26 00:15:06 2010 -0500
make singleuser its own config section
commit 786ab260a3ca172e57b555c75ca10946d8f258a1
Author: Evan Prodromou <evan@status.net>
Date: Tue Jan 26 00:05:19 2010 -0500
make single-user mode work
commit 5b21d7309b3a8dd5a4e0f29aea76f7897f1818b1
Author: Evan Prodromou <evan@status.net>
Date: Mon Jan 25 23:45:55 2010 -0500
add single-user mode
This reverts commit 81b4a381d9.
IMO "user" is a bit impersonal and we shouldn't go changing the tone of the UI willy-nilly when we're updating localisations.
For various reasons, it's nicer to have a class for theme-file paths
and such. So, I've rewritten the code for determining the locations of
theme files to be more OOPy.
I changed all the uses of the two functions in the module (theme_file
and theme_path) to use Theme::file and Theme::path respectively.
I've also removed the code in common.php that require's the module;
using a class means we can autoload it instead.
