[pLog-svn] Announcing SoylentX.com powered by a souped up Plog

[Oscar Renalias]

Great feedback! Thanks a lot :)

> > What is the aim of the site? Is it some sort of "generic" free
> > blogging site?
> >
> The site is still learning to fly. Let me see if I can't give it a
> 'pitch.' Recipe for SoylentX: Take 2 cups multi-user blogging software,
> add 1cup community features, a pinch of design, stir until all
> ingredients are thoroughly mixed and pour into web 'zine mold. Sprinkle
> liberally with interesting people. Bake at 350 degrees until cultural
> revolution rises. Remove from oven and eat hot.

Do you have any test user so that we can see the inside? :) I wouldn't
like to create a test user just for the sake of it...

> > About the changes you made, is there anything you think it's worth
> > trying to add to the development version?
> 
> Its hard to say. I want to fold some of the most recent work, especially
> caching features and anything that improve performance back into my
> branch of plog. I think then I'll be able to say more. Database sessions
> would be worth including in core. I actually had a little problem there
> that I solved in a really, really kludgy way I'm afraid, but that's for
> another post. 

I remember you sent me some code regarding db sessions a while ago. I
am still planning to merge that into the main trunk but I haven't had
a chance yet, basically because it still needed some polishing (I was
planning to implement different session backends instead of dropping
everything into the same class) Did you ever clean this feature up or
should I start working on my own?

Also, what's the kludge about?

> I need to put some polish on my extended user profile
> plugin and re-release that. There's lots of little things here and there
> that might be good for the dev version. I had trouble when I installed
> one of the patches that would keep people from overlapping blog names.
> It had to do with tacking a number,userid, onto the mangled blog name,
> for some reason that didn't work for me so instead I just validated the
> name when it was entered and disallowed duplicate names. I think it
> would be nice if there were two names associated with blogs, one would
> serve to identify which blog to serve: the subdomain part, and one would
> actually show up in templates and such: more like a title. That way you
> could have short catchy urls but have them expand to longer names in the
> templates. I didn't implement this feature but its definitely a core
> hack. I changed the way the login works. Now if you login the dashboard
> is integrated with the rest of the "menu" its the default page instead
> of "write and article" also I use a little js driven drop down in the
> upper right corner to switch between blogs. 

The js menu is something we could add to the main plog, as an addition
for quickly switching from blog blog instead of clicking through the
dashboard for those who are concerned about mouse clicks. I'd like to
see how you implemented it, though.

What I don't understand is which blog you show when logging in. The
first one to which the user belongs?

> I think this alone makes it
> a whole lot less confusing for your average user. I like it better too
> because there are less 'clicks' involved. But actually the logged in
> state, dashboard and navigation and everything is something that I still
> want to work on. I think what I have is better than the default setup
> for myself and my site's members. I don't know if it would be for
> anybody else or not.

As I said, I'd like to see how it feels :)

> > What features did you add?  How did you get those different feeds
> > categorized as "culture",  "technica", etc? Did you implement some
> > sort of global blog categories?
> 
> I, yeah, I hacked it. Its dirty. Tried to make it a plugin but it works
> for when I, as the admin, add a blog, but not when new users sign up. I
> just made sure that instead of only adding "General" as a category that
> I added all those default categories. People can still add their own if
> they want to customize their blog. This could probably use some work,
> definitely on the technical side as its dirty, but I think it needs to
> wait until the conceptual side can catch up. I have to see what my
> people do with it. It's been very educational to switch from my old site
> to this new one. Watching how people use it versus the old one and
> listening to feedback.

Global categories have already been asked a few times so looks like
we'll have to implement them. Not earlier than 1.2, though (as Mark
suggested, 1.1 could be a "performance improvements" release while 1.2
could be a "community release" sort of thing)

> > One more thing about the changes: is there anything we could do to
> > make the customization work easier in the future? I'd like to hear
> > your opinions on this :)
> 
> A lot of what made customization difficult was learning the Plog API.
> I'm by no means an expert but I know how to get around now and I have a
> pretty good idea of how to accomplish what I want. I think one of the
> most valuable things was being able to ask question and get the answers.
> As I've said before better organization of the documentation, I
> know....feel free to jump in and fix it, would help. Sometimes I
> couldn't find something, or worse, didn't know what I was looking for or
> that it even existed. The API Doxygen site was very helpful. I actually
> installed that and generated my own docs but I like using the online one
> better. I'd suggest that you create separate Doxygen docs for each
> version of Plog. Don't pull 1.0 once you put up the newer ones.

Thanks, we'll keep it in mind when updating the docs to 1.1.

> THE BIGGEST PROBLEM with customizing Plog is one that every OS project
> faces. I as the user/developer want to hack the core so I can make Plog
> do exactly what I want it to. BUT I also want to take advantage of
> developments and new versions. How do I do this? (That's rhetorical, but
> if you have any really good suggestions....) I can use SVN and
> diff/merge but I'm not an old hand at this and its very tedious work
> merging code like that. I would love to see a discussion or even
> documentation of the best ways to go about this. 

Technically speaking, you should be able to make your changes on top
of a working tree periodically updated from svn. The svn client will
take of merging all new changes with your own local changes... the
only difficult situation being conflicting updates, which may possibly
happen. I think there was a discussion in the forums not long about
this, was it with you perhaps?

> One thing that struck
> me after I had completed 99% of the work was I wish I was able to create
> classes that extended core classes rather than hack the core classes. So
> let's say I want to change a couple queries in the 'users.class.php' DAO
> I could create 'users.class.ext.php' and just override or add methods to
> this file instead. That way when I want to upgrade the core I can pretty
> much just overwrite all my old core files. None of my changes will get
> touched and as long as all the interfaces stay the same everything ought
> to work. Its probably not that simple, but at least I would have all my
> custom changes sitting alone in separate files instead of being wrapped
> all up in the core code. This would also make it easier to diff the old
> core version, which is no longer hacked up with mods, with the new
> version since I could really just see what changed in the core and not
> have to worry about every line. This would make customization so much
> easier and less of a headache for developers. I'm not certain how one
> would accomplish this dynamic loading of classes but it would be cool.
> (After rereading this paragraph... YEAH! Think about this. Would be a
> killer technique for OS projects, also maybe call the files .mod or .hack)

I've been thinking about this since I read your email yesterday and I
see no easy solution... Let's say that you want to extend the
functionality of the "Users" class to add a couple of methods of your
own. One possibility would be to extend the Users class, call it
UsersExt but difficulties come because of this:

$users = new Users();

we're creating an instance of Users and not of UsersExt so unless we
replace "Users" with "UserExt" this everywhere, this won't work.

A second option would be to rename plog's core Users class to
UsersCore and save your own class as Users, which would extend
UsersCore. Since the name of the class hasn't changed, this would
ensure that no extra changes are needed elsewhere. When upgrading to
newer versions of plog, you'd only need to remember which classes you
renamed and which classes are your own. Something related to this
would be to ship plog with UsersCore implementing the code and Users
as a simple class extending UsersCore but providing no code so that
users could easily add there their own custom stuff.

Yet another option would be to have all DAO classes behave like
'proxy' classes (or was it the 'facade' pattern?) in which they're
just a simple "pretty face" for another class that actually does the
real work. This is the approach that was taken to implement the
generic user data integration in 1.1, look at how the Users class
looks like now:
http://www.plogworld.net/svn/plog/plog/trunk/class/dao/users.class.php
It's just a bit of common code and everything else are calls to
$this->_provider->whateverMethod() It adds an extra level of
indirection, but it also allows to easily to swap between these
'worker' classes without affecting the interface of the main DAO class
such as Blogs, Articles, etc. Via some very simple configuration
file(s), we could specify which 'worker' class is used by which DAO
class without affecting any part of the code.

The only problem I can see is that you're limited by the interface of
the main DAO class. Let's say that if Users::authenticateUser() takes
2 parameters and you'd like it to take 3 because you need some custom
stuff, you will still need to modify the interface in Users() and then
the implementaiton of your custom worker class...

A fourth option (I told you I had been thinking about it, remember?
:)) could be to replace this

$users = new Users();

with this:

$users = new_Users();

or even something like this:

$users = DAO::getUsersDAO();

These two new functions would check somewhere (config file,
plog_config db table) which class is responsible for dealing with
users. It is very similar to the third approach but without the extra
level of indirection (and it needs a few more changes here antd there)

Opinions?

Oscar