Since commit c4072ef7c9 in March there's no longer an automatic run of $this->getNotices() from RssAction parent class; added to the subclass.
It might make sense to put it back in the parent class, but of course only if those dupe calls can be resolved.
Since commit c4072ef7c9 in March there's no longer an automatic run of $this->getNotices() from RssAction parent class; added to the subclass.
It might make sense to put it back in the parent class, but of course only if those dupe calls can be resolved.
Caused failures saving profile settings with Geonames plugin enabled; the lat/lon/id fields would get re-set with freshly looked up values which no longer matched the previous values as far as the data object could tell, but which saved as the same ol' numbers.
User links using the ID number (such as created for @-replies) have been failing on Internet Explorer, since IE doesn't bother to actually say it supports text/html...
We usually get something like this from IE, up through at least IE 8:
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
The */* ended up matching application/rdf+xml instead of text/html, so only other browsers which are more explicit would actually get sent on to the user profile/notice stream; IE visitors were directed on to the FOAF download. :(
Swapping the order of items in the server-side of the negotiation list fixes this; clients actually asking for FOAF at a higher priority than HTML will still get it, but the wildcard */* now matches text/html which is usually what we want.
Content negotiation for the user links was added August 2008 in commit 48fcfb8b0d.
Added EmailAuthenticationPlugin
Added ReverseUsernameAuthenticationPlugin
Changed the StartChangePassword and EndChangePassword events to take a user, instead of a nickname
User::allowed_nickname was declared non-static, but used as if it was static, so I made the declaration static
* 0.9.x:
Added a events for the settings menu items
Bringing Sphinx search support up to code: broken out to a plugin, now supports multiple sites on a single server.
Changed to Evan's event style and added an AuthPlugin superclass
add geo output to statuses in json, xml, atom, rss in API
Localisation updates from translatewiki.net (2009-11-10)
Localisation updates from translatewiki.net
Update pot
add lat and long parameters to api/statuses/update
change credential check to work more like other events
fixup output of object attributes in db error code
Performance fix for subscription/subscriber lists based on feedback from ops.
Adjusting indexes to make favorites query more efficient, based on feedback from ops.
Revert untested code; spews PHP notice warnings on every page view: "just sent a http 200 for the check-fancy from install.php"
Added hook for the Group navigation items
Updated block @title text (shouldn't say from group)
Updated group block markup
Revert "Remove more contractions"
Upgrade notes:
* Index names have changed from hardcoded 'Identica_people' and 'Identica_notices' to use the database name and actual table names. Must reindex.
New events:
* GetSearchEngine to override default search engine class selection from plugins
New scripts:
* gen_config.php generates a sphinx.conf from database configuration (with theoretical support for status_network table, but it doesn't seem to be cleanly queriable right now without knowing the db setup info for that. Needs generalized support.)
* Replaced old sphinx-indexer.sh and sphinx-cron.sh with index_update.php
Other fixes:
* sphinx.conf.sample better matches our live config, skipping unused stopword list and using a more realistic indexer memory limit
Further notes:
* Probably doesn't work right with PostgreSQL yet; Sphinx can pull from PG but the extraction queries currently look like they use some MySQL-specific functions.
* 0.9.x: (26 commits)
just sent a http 200 for the check-fancy from install.php
Add a new event: CanUserChangeField
shorten flag notification and include a class
Added flag icon for UserFlag plugin
Fixed notice option alignment in IE
add a method to Theme class to list available themes
Updated Realtime plugin to use the util's NoticeReply object
Localisation updates from translatewiki.net (2009-11-08)
Update pot again
Rebuild pot file *without* --join-existing to get rid of the cruft. Not sure why "--join-existing" must be in. Only thing I can think of is manual additions, which I could not find.
Revert "More precise field label"
Remove more contractions
Revert "* [Cc]an't -> [Cc]annot"
Revert "More specifics on 'address'"
* [Cc]an't -> [Cc]annot
Revert "* check usage of 'people' in UI and change it to 'users' or something else in most places"
add utilities for calculating local and installation theme root dirs
Harmonise UI message "No such user."
Restructure theme.php to define a class Theme
entity_action responses look more inactive now
...
This reverts commit 6483fbd8fa.
"SMS address" header here makes no sense; it would be inconsistent with the other tabs and headings on the same and related pages, and would look very awkward with another giant "SMS" right above it
This reverts commit 1872d07602.
"instant messages address" is very awkward phrasing; prefer not to be changing UI in such ways while updating localisations.
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.
doesn't like the XHR response with XHTML DTD. New notices without the
file attachment work fine.
The rendered content (the anchor for the file attachment link) doesn't
appear to be the issue.
To fix this problem, I removed the XHTML DTD line from newnotice's XHR
response. This is unnecessary for text/xml outputs that's intended
for XHR responses any way. It just happens to fix an IE issue.
Still a mystery to me as to why it is particular to notices with file
attachments.
doesn't like the XHR response with XHTML DTD. New notices without the
file attachment work fine.
The rendered content (the anchor for the file attachment link) doesn't
appear to be the issue.
To fix this problem, I removed the XHTML DTD line from newnotice's XHR
response. This is unnecessary for text/xml outputs that's intended
for XHR responses any way. It just happens to fix an IE issue.
Still a mystery to me as to why it is particular to notices with file
attachments.
Added 4 new events involved in XRDS: StartUserXRDS, EndUserXRDS, StartPublicXRDS, EndPublicXRDS
Added OpenID provider functionality (no delegation support [yet])
* api-media-upload:
Rearanged a couple things & removed debugging statements
Rework MailDaemon to use the MediaFile class for uploads
Implement media upload in the API
Extract media upload stuff into its own library class.
of empty notice prefix text in facebook settings.
Filed bug upstream at http://bugs.developers.facebook.com/show_bug.cgi?id=7110
Per documentation, saving a pref value of "" or "0" will delete the pref key:
http://wiki.developers.facebook.com/index.php/Data.setUserPreference
which used to do what we want... Now Facebook throws back an error
"Parameter value is required" when we do this. Workaround appends a
space to empty string or "0" at save time, then trims the string when
we load it.
The input string was already trimmed at pref save time, so this won't
alter any user-visible behavior.
Thanks to ^demon in #mediawiki for pointing out the behavior regression
after testing the identi.ca Facebook app!
of empty notice prefix text in facebook settings.
Filed bug upstream at http://bugs.developers.facebook.com/show_bug.cgi?id=7110
Per documentation, saving a pref value of "" or "0" will delete the pref key:
http://wiki.developers.facebook.com/index.php/Data.setUserPreference
which used to do what we want... Now Facebook throws back an error
"Parameter value is required" when we do this. Workaround appends a
space to empty string or "0" at save time, then trims the string when
we load it.
The input string was already trimmed at pref save time, so this won't
alter any user-visible behavior.
Thanks to ^demon in #mediawiki for pointing out the behavior regression
after testing the identi.ca Facebook app!
