Re: [pLog-General] features
Brought to you by:
jondaley
From: Nick G. <ni...@so...> - 2004-03-11 04:58:54
|
Oscar Renalias wrote: > Let's see... > > >>Some list revisions: >> (1) Books/Albums - I've got a couple different views on this and it >>could be done multiple ways. The first would be assigning related >>entries at blog creation. The second, a more complicated but more >>sophisticated way, would be creating a 'book' and then creating entries >>and assigning them to be viewed inside that book. With the second method >> it would be comparible to a seriously hacked catagory system with >>unique catagoris (name & id). Once the book is created and the entries >>are done for it you could edit the book's properties and assign paging >>order, view prefs, etc. The motivation behind this span. First is for >>papers, research papers and the like that are just too big for one >>entry and would seem clumsy and unproffessional with mulitiple blog >>entries. Another would be for tutorials and walk throughs. I've written >>a couple articles for devarticles.com and others and would really like >>to see something like this implimentable on my own site. > > > Perhaps it would be easier to use and understand this feature if we change > its concept a little. We could say that a post can span across more than > one page, rather than saying that we can link several different posts and > make them behave like pages. Pages could be added, removed and reorganized > anytime. > You got me thinking about just splitting an entry between pages. Maybe adding a metadata tag that woulc contain the page number, title, etc. Another way to do this would be using div tags with metadata tags inside the tag giving title, etc. Kinda like an anchor effect. Just ideas. > >> (2) Moderators - This would be an aproval system for blogs forcing >>entries that a user would like to be published to be reviewed by a >>designated 'editor'. In essence the blog owner would designate an user >>as the moderator/editor of a particular blog, yet still retaining rights >> to his own blog, thus forcing all entries to be scoped out before made >>public and final. > > > Two options: > > 1) We add a forth user level called "moderator". > > 2) We assume that the owner of a blog can toggle a setting in the > properties of the blog that says that posts added by other users have to > approved by the owner first, and add another status to posts called > "approval pending", or something like that. > > I happen to like the 2nd more :) > Yeah, second idea sounds much better. > >> (3) Backup/Restore - This could be done as a plugin actually. Would >>probly be alot simpler that way as well. This is for the >>newbie/intermediate who doesn't have access to mysql dump or an >>interface to mysqld. Its unfortunate but some webservers don't allow >>that sort of access to users. > > > Yes, you are right that some hosting services do not give full access to > tools like mysqldump but they still offer other tools like phpMyAdmin. But > I could have a look at implementing this. Making a backup of a blog/whole > site is really easy but restoring it on top of a running pLog is not so... > I'll see what we can do :) > Wouldn't be hard to create a small script that front mysqldump or something similar. I'll look into it and shout back with results. > >> (4) Catagory work - I have a couple different views on catagories and >>how they are handled. For one it'd be nice to have subcatagories like: >> School >> ~ French Class >> ~ Homework >> ~ Papers >>or something along those lines. The other main thing is the ability to >>set a master catagory for an entry but then have additional catagories >>that the entry would be viewed under. > > > We actually have something similar for resources: every album can have a > parent album and more than one child album, but a resource can only belong > to one album at a time. But if you use this kind of "hierarchical" > categories, you don't really need multiple categories per post, do you? > I know about albums and it wouldn't be hard to have children, you could simply add recursion based on parent_id in table x. But i figure if your going to go all the way with sub catagories might as well go big with multiple catagories. > >> (5) Keywords - Having a quick and low resource hogging seach ability >>would be very handy for those who write reviews or articles and have >>hundreds, or more, entries on their site. The most simplistic method of >>doing this would be by having an additional field at entry creation for >>specific key words, topics and/or subjects. If you really wanted to go >>all out you could create a fuzzy logic class that weeds out all 'common' >> words and creates an index of searchable fields for that entry. It >>wouldn't be hard, i've done that in c++ for a mud before. As for >>conversion who knows but, i have some stable ideas on how it could be >>done, fyi. > > > I have already started planning the search feature, and we will use the > text indexing and searching features provided by MySQL since it's the > easiest way. Then we should only combine, somehow, the results returned by > the MySQL with the metadata keywords that we have stored and show the > results to users. > > Btw, what was the theoretical base behind the class you developed? How > does it know what is common and what's not? > Its based loosely, VERY LOOSELY, off of an engine used to create searchable toc files for help systems. It removes all common words (if, then and or but when how etc etc etc) and looks for base nouns and adjectives/adverbs while comparing it to previous entries so you don't have 30 records of all similar keywords/phrases. Also did something like this for gtk-spell, a gnome spell checker. > >> (6) Karma - A karma system could be plugin based using a few carefully >> >>structured tables. One main for the listing of each blog with a >>non-defaul karma rating, anything not 0. Then for each modification just >> adjust the rating for the entry. If you wanted to be a bit more >>controlling you could have a table setup with a listing of all >>modifications made to entries: >> id int, user != 0 (guest), ip, timestamp, blog id (xor book id), >>pos/neg rating >>this would prevent multiple posting of karma ratings etc. > > > Having an additional script handle submissions of "karma scoring" wouldn't > be very difficult. As you said, an additional table where to store those > scores would be more than enough and to make a post disappear because of > bad karma, we could just set its status to "draft". One problem that we > need to overcome: if a post is set to "draft", it won't be possible to > access it anymore, not even if we have its permalink. > > But how should it work with posts that have a bad karma? Should they > completely disappear from the main page, the list of recent posts and the > archives? Or should they only disappear from the main page? > I would never actually set a page to draft, unless a user wanted something with like -60 karma to go draft, because with enough bad karma a group of people could effectively remove alot, if not all, content from a site. If an entry has some sort of range of bad karma, say -1 to -100 (min-max bad) it is not shown on the main page or summary page. You'd have to either search for it or go directly to the entry. Also the article would be flagged as having bad karma and could possibly prevent users from seeing the preview/desc of it under its catagory view. I'm not fond of complete removal. > I like this discussion :) But I am not going to add any more feature to > the admin interface until we redesign it... It's way to ugly and > cluttered, and the top menu bar has become too small (have a look at "Site > Admin" tab, it doesn't fit on my screen unless I resize the browser's > window to take the whole 1280 pixels wide!) Does anybody have a good idea > about how it should be? > > Oscar > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > pLog-General mailing list > pLo...@li... > https://lists.sourceforge.net/lists/listinfo/plog-general > > > |