[Phpslash-devel] RE: [phpslash-users] Possible Extensions
Brought to you by:
joestewart,
nhruby
From: Peter C. <pe...@we...> - 2002-04-16 11:33:40
|
[Transeferred to developers list since we're getting techie here] > On Mon, Apr 15, 2002 at 05:47:58PM +0100, Peter Cruickshank wrote: > > Hi you all > > > > I'm gearing up to produce a phpSlash site for a real client. > > > > great news. Thanks! > > As part of that, I'm extending Sections to allow for nesting > (ie one section > > can 'own' sub-sections - with extra options to allow a section's > > sub-sections to be listed; I'm just about there, apart from > breadcrumbing > > and preventing loops). This makes phpSlash into something much > more like a > > CMS, IMO. Any interest in me uploading the changes, once they've settled > > down? > > yes, please contact me with details. OK here goes: >>> Database psl_section: new field, parent_id (int(11) default '0') >>> Templates sectionList.tpl: added fields to show/allow selection of parent (no nested indents or anything yet) sectionNew.tpl: added field to show/allow selection of parent >>> Code * section.class: new method to generate a dropdown list of possible parents. * sectionAdmin.php3: methods to take parents into account when saving, displaying and deleting. (On delete, children's parent_ids are set to the deleted section's parent) * functions.inc - [to do] change breadcrumb() to list the full path from the current section back to [home] * block_render_section.class Now has these url parameters tree = [] | 1 - if set, restricts list to immediate children of the given section (could be extended to say how many levels of the tree to show) section = [Home] | sectionname Only used if 'tree' is set section_id = [3 or whatever] | section_id Only used if 'tree' is set mode = [] | all - if set, all sections are listed even if they have no articles Amongst other things, it is now possible to post stories to the Admin section and still not have Admin appearing in the section list on the Homepage. Question: Which would you say the preferred aproach - block options or url variables? block_render_rss uses block options, block_render_section uses the url... I've attached my working files in case they're of interest. (NB I'm using .php not .php3 in this project). > > I also want to allow images and documents to be uploaded with stories > > (possibly only by authorised users). Has anyone done this > already - would > > you be willing to share the code with me? Else - would this also be > > something that would be of interest generally? > > > > Luis has a patch submitted to post a story from a file upload. Yeah - I'll have a look at it. > I've been put off with the variations in installations and permissions. > So it would be great to get this going. See my reply to Sam Williams's post > > Finally - event logging. There's a note somewhere saying that it needs > > updated + I can see why! > > If I were to update logging - what do you think should be > tracked and how? > > > > I've thought of: > > - article reads (recording article id) > > - visits to index.php (recording section_id and topic_id) > > - admin actions (similar to current, but keeping user in a > separate column). > > I know there's a performance/load issue here, so the maybe it should be > > possible to choose the level of logging. > > > > We need a decent stats screen too... > > > > Any thoughts? > > > > My big worry is the performance/load issue of course. > > A possibility would be to log the information that is contained in the > apache combined logfile format too. > > Another issue is if we increase the use of caching pages. Some > information may not get updated correctly. See my reply to Sam Williams's post for this too. > > Nathan/Joe - I know this stuff is probably not in your current > plans. I need > > to make them now, but I reckon it would be good (if they work) > to bring them > > back into the development path when the time is right. If ever! > > Like you said, you need them now. So hopefully we'l l be able to fold > them in. > > We're trying to open up the roadmap to other development than what is on > our own plates. It's more work for you guys - but hopefully it'll pay off in speeding up development. Of course, it's important to keep consistency... Thanks as always for the feedback! Peter |