Site redesign/rebuild

From Splatspace
Revision as of 13:56, 5 July 2013 by Petesoper (Talk | contribs)

Jump to: navigation, search

This page tracks requirements and requests for a new site.

Contents

Problems with existing site

  • Bad styling on posts
  • Info for new members and interested parties can be hard to find
  • Wiki is infested with spam content and accounts. (To become instantly aware of this, try a search for almost any keyword you'd like to look for, such as "membership")
  • Other (abandoned) site(s), various labels we use (e.g. durham makerspace) compete with the Splatspace identity and create terrible confusion

New site

Requirements

  • Easy to use/update blog
  • Important info super easy to find

Nice to haves

  • Better mailing list integration/sign up
  • Meetup integration
  • Flickr integration

Implementation Details

  • Using a recursive wget pointed at http://wiki.splatspace.org a start on a white list can be created. This list of URLs and all the files downloaded this way are available.
  • By figuring out things that have to be done, or we think have to be done, some work could be accomplished before meetings, maybe saving some of us from blocking a lot at a meeting. Some items like this, such as establishing WHAT ALAN AND ONLY ALAN CAN DO, are critically important to determine before the meeting.

Some wiki-naive notes about what the spam problem and fix might involve

  • Here's my notion of what's needed after discussion with Chris and Shaw:
  • The wiki needs to be carefully backed up, the SQL database behind it needs to be carefully backed up, then:
  • The wiki config needs to be changed (and maybe the wiki restarted?) to disable account creation and disable edits by any but privileged users.
  • SQL access to the wiki database is needed to extract userids. \Then we need to identify the ids corresponding to valid users if possible. That is, correlating known-good content to ids or just knowing who's who in cases where weird aliases are not employed is needed to approximate a list of non-spammers. The wiki interface allows screen-scraping the early batch of account creations that came before the spammers. Then the edits made by not-OK userids need to be unwound. Where valid edits came in afterward some kind of merge may be required. Some kind of creative communication is needed to ask folks if their content disappeared, and if so, it has to be restored. New account creation would then be set up as a moderated process and then access restrictions would be lifted.
  • No doubt this is incomplete/wrong in spots, but this is the overall scheme that was waiting for some initial SQL experiments.
  • For folks who know what they're doing the steps up to the unwinding might only take a few minutes (and could presumably be done before the get together). The unwinding/merging might be purely mechanical but might involve some serious eyeball/think time.
  • As I recall it wasn't at all clear that anybody but Allen could modify the wiki configuration to disable the account creation and restrict edits, as it seemed like the permissions required sudo, but it's been a while now and that might have been an illusion.

--Petesoper 11:59, 28 June 2013 (MDT)