This project is read-only.

BlogEngine.NET Admin

Apr 13, 2009 at 7:43 PM
Is anyone on the team working on an update to the admin?  The BlogEngine.NET platform is great but the Admin needs some TLC.

If not please let me know, I would like to try my hand at it.

Apr 13, 2009 at 8:53 PM
Do you mean some of the items listed in this issue, for example?

You're of course welcome to chip in.  Although, you might want to double check to make sure a particular item is not being worked on by someone else before you work on it.  It's also possible that some changes may not be wanted for BE.  Not sure what that would be, but there's always the possibility.  Even if it's decided something shouldn't be put into BE, it doesn't mean you can't create it for yourself and for other people to manually add to their BE installation.
Apr 13, 2009 at 10:35 PM
Can you give me an idea of changes that may not be wanted?

I think many of those items are good but for now I would add more blog entry management.  Specifically I would like to improve draft handling and would like to add scheduled posts.  I would also like to add Tag management - much like Category replacement is now.

I think there are also some smaller things that would make nice changes.  Time zone instead of time offset in settings.  Control the date/time format from the admin.

Last of my ideas is that the admin UI needs a refresh.  For that though I have a different suggestion.  It might be a lot of fun for people to be involved in a contest to see who can create the best admin UI refresh.  I could put in an entry too but more important from the winner I could implement the design in the admin with all the necessary code changes to help implement the theme.
Apr 13, 2009 at 11:19 PM
I'm pretty sure that after 1.5 is released, the Commentor extension (or some part of it) will get put into BE.  So that would be an area you wouldn't need to work on.

The only other type of item I can think of that probably wouldn't make it into BE is something that requires a third party assembly or DLL.  That's one of the reasons OpenID login isn't yet in BE.

A more colorful UI in the admin settings would be nice :)

I'm not sure the advantage of time zone over time offset.  If it was time zone, I'm thinking the offset would still be needed in some form just because a number of places within BE are adding and subtracting the offset into the timestamps of posts.

You may be aware that scheduled posts are basically already available in BE.  Posts given a future timestamp aren't visible until the time on the post has arrived.  Unless you're logged into the blog ... then you see future dated posts too.
Apr 14, 2009 at 12:50 AM
Edited Apr 14, 2009 at 3:37 AM
Techically you would still have a offset, its actually should be a simple change - just need to create a method to figure out the offset -  its just more user friendly to select timezone.  I can get the servers timezone - in my case pacific and the server sees my timezone is central and subtract the two (-1) to get the same offset I entered into the box.  I am sure that you just pull the value out of the database and assign it to a variable - instead could just put a method call in its place.  Same with the date time formatting, I am about finished bringing over the Freshy 2 suite of themes and was a little concerned that date formatting was left up to the theme.

An aside - I really like that extension framework - I've created a simple extension that manages sub themes in the suite.  I attached the theme settings to the admin menu control.   When a selection is made beside the default the master page pulls the subtheme css file and loads it into the header.

I guess I actually was aware that I could set a data ahead of time.  I was more thinking that in the manage interface there would be a distinction.  That way you could tell easier what posts are scheduled ahead of todays date.

I wasn't thinking of Open ID but it would be a good idea for the comments system.  I am a little suprised though, I don't know why we would need a third party library at all, should be able to accomplish open id with a simple javascript library like this:

If all of that sounds OK I can begin working on it this weekend.  What is your code review process? Should I just create a new entry under Issue Tracker - upload the code there and reply back to this entry?
Apr 14, 2009 at 4:48 AM
.NET 3.5 actually includes new functionality to get timezone information for any timezone.  I wrote this blog post about it.  I'm pretty sure that thru .NET 2.0, timezone information for a zone other than the machine the .NET application is running on, was not obtainable.

However, the website project in BE is currently only using .NET 2.0.  The BE core is using .NET 3.5, but we're not yet using any new classes introduced in .NET 3.5.  The only .NET 3.5 features being used are compile-time features such as automatic properties and lambdas.  This is intentional so BE users aren't required to be on a .NET 3.5 server.  It may still be possible to get an offset between the selected time zone and the server time zone with .NET 2.0 libraries ... but I haven't looked into it.  If you can come up with it, that would be nice.

A time zone setting may be more user friendly than an offset, but I'm not sure if a lot of people have problems with the current offset.  For me, a more tangible advantage I can think of with a time zone setting rather than a time offset setting is when the offset is not the same throughout the year.  If one time zone observes DST and the other doesn't, then the offset is not always the same and the person needs to update the offset twice a year.  So using a time zone rather than offset would help with this -- as long as BE didn't calculate the offset once and permanently store it.  It would need to re-calculate it every so often.  Or maybe after calculating it, if BE also knew when DST starts or stops, it could store the offset in the .NET cache with an expiration date of when DST starts/stops.  With this approach, the offset is re-calculated when the offset could potentially change.

An improved interface or way to distinguish future dated posts would actually be nice.  A few people here have posted questions because they were confused thinking future dated posts were visible to everyone.  They didn't realize the only reason they could see the future dated posts was because they were logged in.  So if this could be more clear to them, it would be beneficial.

The only hesitation I have with the Open Id JavaScript library you pointed out is its dependency on jQuery.  I just looked at that library, and it looks like it could pretty easily be converted to not use jQuery.  Maybe BE could include jQuery, though.  Up till now, BE hasn't used any JS frameworks.  I'm honestly not sure if that's something the team wants to start including.  But there's enough people wanting Open ID support, that something like a jQuery dependency shouldn't get in the way.

Yes, uploading your code in the Issue Tracker is a good place.  It can be can be reviewed and commented on there.  You can also update this post too.

P.S. If I sound too pessimistic, or am picking at your suggestions too much, it's not intentional :)  I'm pretty new to the BE dev team, and am not familiar with all the rules and guidelines the team adheres to.  So, I'm just erring on the side of caution.