RE: [phpslash-users] Possible Extensions

[Peter C. <pe...@we...>]

Hi

> My apologies to Peter who has received this twice because of my
> ineptitude!

Three times actually :-)

>
> On Tue, 2002-04-16 at 00:47, Peter Cruickshank wrote:
> > Hi you all
> >
> > I'm gearing up to produce a phpSlash site for a real client.
>
> Great news - I also got a client to sign for a phpSlash based site last
> Friday! It's great being paid to spend time on phpSlash code :-).

Too right!

> > 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?
>
> All this was in my todo list (I can't start on this project for another
> week), so I would love to take a look at your code. I am all for moving
> phpSlash towards being a content management system - I think it would be
> more flexible and it could still be used as a weblog without much
> trouble... however, not every one might agree with me on that!

That's what I think too.

I posted a more detailed reply to Joe in the developers' list giving details
of the changes. The main thing is that when creating a section you can
define its parent from a dropdown list.

The section block now has these parameters:
tree = [] | anything - if set, restricts list to immediate children of the
given section
	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

I'm also tempted to add a 'description' parameter while I'm at it...

> Some of the other things I am thinking about implementing are separate
> topics for each section and author permissions for sections. My current
> client is particularly concerned with limiting what is put up by the PR
> dept. to their own section - he thinks they will try to over-run the
> rest of the site given a chance!

I've thought about that too (see feature request 513264) ... but now I'm
worrying we could end up with something like postNuke's permissions system
which is powerful and flexible, but really slows the thing down. I think
this is something to think about quite hard. Joe/Nathan?

> > 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?
> >
>
> I am customising the story entry page by providing buttons (javascript)
> that will insert html tags into the "story" at the cursor (like
> http://www.cris.com/~raydaly/hjdemo.shtml). This way users with no
> knowledge of html (most of them) can put headings, bold text etc in
> articles. One of those buttons will be for image upload - I was thinking
> about sticking the image in a directory, generating a thumbnail for
> display in the story and inserting the appropriate javascript in the
> story so that clicking on the thumbnail pops up the image in a new
> window... I'll put the body of the function in a global js file linked
> in slashHead.tpl.

This would be good! There's a problem with commercial use of the guy's code
though; are you writing your own version or is there any GNU equivalent?

> I don't know what your opinion is, but I would rather keep images on the
> filesystem than in the db. Only trouble is, it's not a very clean
> solution when deleting a story as the images will be left behind...
> perhaps each story should have a "./images/<story_id>" directory that is
> deleted when the story is removed from the db?

Fair point about the need for a directory per story. I planning to be more
simpleminded with the image (and document) uploads - just saving them in the
directory and building a reference to the image into the template (I want my
images to illustrate the story, so pop-ups aren't ideal).

<snip>

 > >
> > 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 wishlist:
>
> 1) All admin actions need to be logged. Option to list by user / action
> / date.

Yup. Need a nice summary format too, which the current phpslash is missing.

> Date and time of last database backup also needs to be recorded.

How do you do your backups?
>
> 2) Attempts to access pages that do not exist need to be logged - if
> lots of people are looking for a page that does not exist, I know there
> must be a dead link somewhere (though not necessarily not on my site).

Can this happen in phpslash?

> 3) Referer info. Perhaps best extracted from apache logs, but not
> everyone has access to these.

Yup - can be gathered in slashHead or similar but looking + logging
HTTP_REFERER that doesn't include the site url.

> 4) Current size of the site (broken into db plus a summary of all
> directories).

Best off the ISP's stats screens?

> 5) The no. of hits each day. This needs to be recorded so we can see if
> new content is improving / reducing popularity.

Yup

> 5) Most popular and least popular stories need to be identified (easy
> one!).

Yup

> Quite a list. I was not going to implement all of this during this
> project, but they are all on my "longterm" wishlist.

Pretty similar to my list too!

My main priority is to have a simple screen(s) so the client can check how
the site's doing, so I need to have screens built into the site, which (I
think) rules out using text log files.

I checked out + liked Mark Smeet's statistics screen; it gives enough
information to start, though I'd like to be able to add some graphs and
colours :-) He's letting me have a look at his code and I'll see how it
goes...

My site will not be high volume (100 hits per week on the current static
site!) so I don't have to worry about processor loads... but any logging
system must have switches to control the volume of data collected.

Thanks for all the feedback everyone, keep it coming!

Phew!

Peter