WikiFlux For PrivateWiki

Lots of the ideas I'm chewing on lately require a Private Wiki Notebook space, so I guess it's time to extend WikiFlux into that. Why?


  • launch local version for first time in ages, ok works
  • pondering data structures - see orig FlaskForWikiEngine notes
    • do I want a single NameSpace? Then "publishing" is just changing the toggle on a node? Nah, I think there are good reasons for TwinPages across private/public.
    • do I want a single user with 2 sets of fields for private and public spaces? Smells messy, will keep decoupled spaces table
    • looks like I have spaces table but no users at all! Hah and my spaces table has no records! (Everything is just in the code.)
  • what amount of generality am I looking to support?
    • could end up hosting this for a few people
    • assume I'd make them use domain - they'd have a unique hostname for identity, and separate paths for wikilog and privatewiki. I'll just force them to use /wiki and /private.
  • db tweaks
    • for now I'll create a pretty raw users table
    • command-line enter single spaces and users records
    • and 2nd spaces record for my new private space
  • next - generalize the routes
    • hack - just double the decorator routes on each function - one for wiki one for private, passing value over


  • now have to make lots of changes to define foreign keys, etc. (grr this is why I like just writing my own SQL instead of playing ORM games)
    • current block: combining join and filter (or filter_by?) - baby steps. Update: fixed.
  • now loading existing /wiki/ pages using new query; recognizing that /private/ page doesn't exist.
  • edit-form link is to /wiki/. Update:fixed
  • form-submit is to /private/ but it actually saves to /wiki/
  • fix the 'POST' logic
  • model has wiki_name_lower = Column(String(128), primary_key=True) but that uniqueness is only within Space, have to modify
  • Multiple classes found for path "Space" in the registry of this declarative base.


  • Realized I had strange composite Primary Key on nodes, fixed that to use space_id, wiki_name_lower
  • (also: restarted app - sometimes I think the auto-reload isn't a full enough reset after certain types of changes)
  • New page created! But error in redirect(url_for()). Derp it's privacy_type not privacy_policy


  • (fixed previous bug)
  • edit existing node: done
  • FrontPage: done, though with wikilog sidebars
  • fixed sidebars, but realize a WikiWord in private renders links to existing pages in wiki
    • also: base url in template is hard-coded wiki - that was easy fix
    • but the render function uses re.sub() which I can't pass an extra space/privacy_level arg to, without wrapping in a lambda, or using a partial. Maybe just use global?


  • actually, needed more work on base
  • went with partial function for re.sub() argument


  • build the quick-capture UX
    • standard URL to hit
    • gives me new-node form; pre-fills title with current date (can edit it to back-date)
    • I fill in body; can fill in Title or leave it empty and it will get auto-generated by first-n-chars of body (plus datestamp)
    • submit to save it
    • haven't built the auto-title-gen piece yet


  • building title auto-gen....
    • it's including the 2nd line, even though I have code to use only first line. Fixed.
    • and it's generating the url but not the title derp. Fixed.
    • and it's doing weird word-capping: TryingAgAinToAutoGenerateATiTleThaT.... Fixed (derp - was doing string-replace of all cases of initial letter!)


  • next
    • make pages Private. Done
    • deploy to live so I can start using QuickCapture all the time


  • deploy to live
    • discover some bad paths - refactor to simplify - use path as privacy_type. Fixed....
    • grr link from node-page to FrontPage not right... ah, it was a constant. Fixed.
  • hrm, hitting not-found page generates error instead of empty-page template. Fixed.
  • InstaPaper autopost broken. Fixed.


  • when QuickCapture auto-generates title, it doesn't strip square-brackets coming from first-line....


  • working on WikiGraph update
    • hrm isn't working right on my laptop
    • could it be related to using sqlite instead of psql for this db? But twinpages.js works but backlinks.js doesn't - have identical structures, just different queries... iterBetter issue?
    • should I just migrate to psql to eliminate a dang variable?


  • derp I realized my local instance was talking to SQLite but I was command-line playing in PostgreSQL. So manually inserted a couple records in the right db.
  • then realized one of my queries wasn't doing the var-interpolation. Finally realized I needed to use %% if I wanted a like wildcard in the query.
  • yikes - realized my public FrontPage was including private nodes once I clicked to since-date group. Fixed.
  • now looks like I need to tweak my Referer parsing some more to cover production path properly for TwinPages. Fixed.


  • upgrade WikiGraph dbs for both private and wikilog. Current process:
    • psql wikiweb
    • copy (select * from pages where space_num={n} and modified>'{date}') to '/tmp/space_nodes.sql'
    • run sql file against my scraper script, to generate the 2 txt files (per space)
    • run those against script to generate pile of sql inserts


  • next?
    • generalize the WikiGraph code to use a single all-spaces export?
    • migrate content?
    • then?
      • then maybe build twitter-scraper to see how that fits on the public side
        • hmm this raises idea of, even having 2 name-spaces for private-vs-wikilog, maybe the private view should be the merge of the 2 spaces?
      • then I'll probably want to tweak FrontPage rendering to handle short nodes differently, mainly to make the title less huge...
      • then figure out whether I want to use transclusion for collections of short-nodes... (hmm see Trimmings library)

Edited:    |       |    Search Twitter for discussion