[pLog-svn] Roadmap/performance

[Oscar Renalias]

On 11 Jan 2006, at 00:30, Christoph Feddersen wrote:

>
>
> Oscar Renalias wrote:
>> If you ask me, I would stick to 1.0.x for the time being. With the
>> proper hardware I think it should easily be able to put up with your
>> expected user-base.
>
> Thanks for your input. I think we'll run a closed test with some
> experienced bloggers to see if 1.0.x meets most of their  
> requirements. I
>  have a list of about a dozen features I'd like to have, but that's
> not necessarily what our users want. If the feedback is positive,  
> we'll
> start with 1.0.x. If not, we'll have to consider which "missing
> features" can be added. Depending on the list's length and the  
> necessary
> changes, going with 1.1 may be more appropriate. I'm thinking of
> pagination for posts, notification of new comments etc.
>
>
>> In any case, let us know what it is that you need to customize
>> and we can probably discuss what the best implementation would be.
>
> Thanks!
> As I already said, we want to accomplish a Single-Sign-On with our  
> current authentication framework.
> Step one would be to use our user table for authentication  
> (loginame, md5 password hash).
> I assume, that a back port of the authentication framework present  
> in 1.1 isn't easily possible?
> So we'll have to enhance the Users class in 1.0.x. Unless I'm  
> missing something, that shouldn't be to difficult.

I don't know if you have already looked at the user-data integration  
framework in 1.1, but basically all we did was this:

1) move all the contents of the Users class to PlogUserdataProvider
2) leave the current Users class as a façade with the current  
methods, and the only thing those methods do is call the right method  
from the "provider".

You can follow the same process in 1.0.x, and this should also ensure  
that the transition to 1.1 is relatively painless as all you will  
need to do is rename your customized version of Users to  
MyUserdataProvider (or whatever), move it to class/dao/userdata/ and  
make sure that config/userdata.properties.php is pointing to the  
right userdata provider. They'll be a few glitches here and there,  
but I wouldn't expect any major problems.

Backporting the whole framework is also possible. The only problem  
might be that the Users class has changed a bit in 1.1 (data cache, etc)

> No my guessing starts for step 2. ;)
> From my understanding, the lifetype frontend doesn't use any  
> authentication/permissions at all? I'm thinking of things like:
>
> 1. Display a link to the admin area when browsing index.php.

As Jon said, you can edit the templates and a static link.

> 2. auto fill username and email when making a comment
>
> That's something our users are used to and we want to implement  
> this for lifetype. So is my assumtion correct? Are there any plans  
> to implement this or can you point me to the right direction?

As Jon said, there is a plugin that remembers users based on a cookie  
set via javascript.

If what you need is the comment form to know whether a user is logged  
in the LT admin interface, then you might need to modify some core  
code to pass this information to the template, and also modify  
commentform.template in all templates to tell smarty to fill certain  
fields with certain values.

> Next "big" thing is the use of subdomains. Currently either the  
> username or blogname can be used for subdomains.
> Our current authentication seperates between a loginname and a  
> username.
> The loginname is used for the login-process only and can be totally  
> different from the username (for security reasons). The username is  
> the "real" username, shown to all users. Unfortunately, our  
> username can contain special characters that aren't allowed in  
> domain names.
>
> Using the username as subdomain would have been our prefered  
> solution, because the Urls would have been easily guessable and  
> everyone would know right away, who owns the particular blog.
>
> For obvious reasons, we don't want to use the loginname, although  
> it doesn't contain any special characters.
>
> Using the blogname would of course work, but I dislike it, because:
>
> - the blogname is used not only for the url, but is also displayed  
> on several pages. From my experience, the "heading" of the blog  
> differs from the the blog's url.
> - our users mainly identify themselves by the username
>
> Maybe the mangledBlogname field can be changed to something like  
> "mangledUsername" during the creation of a new blog? Changing the  
> functions for determing the mangledBlogname should do the job, right?

Yes, I think so... Just remember to store the right values in the db,  
it could be that we have a few hardcoded calls to Textfilter::urlize 
($blog->getBlogName()) in CustomRequestGenerator instead of calling  
$blog->getMangledBlogName(). I seem to remember that I had some  
trouble in 1.1 in this area and hard to work in some clean-up work in  
the custom request generator.

Oscar