Tue 15 Nov 2005
This is a new blog theme, a modified version of Connections. I changed the header image, and pretty much every other image and stylesheet (changed the hue from greenish to blue-ish).
In addition, the blog root now rests at http://oceaninformatics.ucsd.edu. The main blog link remains the same.
Check out the Live Archives plugin on the Archives page (the top nav bar). It’s pretty sweet and uses AJAX and stuff….
More to come about the new blog/appearance/migration/etc. This post is acting as a quick FYI.
15 Responses to “Testing New Theme”
Leave a Reply
You must be logged in to post a comment.
November 15th, 2005 at 6:07 pm
Very nice. Looks good. How difficult is it to change themes?
November 15th, 2005 at 6:09 pm
I like this better than the tabbed theme of old. That was a bit confusing IMO
November 15th, 2005 at 6:21 pm
Jerry,
It wasn’t too difficult to change themes, but maybe that’s because I have some experience with doing this stuff. I studied up on the WordPress Documentation which is really well written (and uses MediaWiki!). Compared to other CMS’s/blog platforms, WordPress makes it very easy to write new themes (and plugins).
The bulk work of this theme was already done for me. What I did was modify it a bit, mainly in changing the color schemes. I wasn’t a fan of the original green look, so I changed all images and stylesheet colors to blue. To accomplish this, I simply changed the hue values for any green color. I increased the hue value for each colored element by 130 to maintain a consistent gradient among the shadings.
Some html elements needed additional tweaking after the hue increment (such as link colors, etc.), so I increased/decreased saturation and/or brightness where needed.
Additionally, I modified the sidebar blocks to contain the same basic elements from the old theme. I also installed a new archives plugin which makes it easy to browse through all the posts.
My main objective is to integrate our (currently) dormant OI Portal Site into WordPress, thus using WordPress as a CMS/Blog. This may require writing or finding an extra plugin or two, but I think it’ll be worth it. To me, it feels like a natural progression to merge the blog with the main OI site, and I feel this new theme provides a better visual framework that can fit everything in.
November 15th, 2005 at 10:55 pm
Shaun,
I agree that the blog (Wordpress seems one of a few ‘best of bread’) feels right. Much cleaner and simpler than the full CMS route. We’re going to try a mixed environment for the SysAdmin group (Mason, Nate and me). We’ll use the WP blog to keep a running journal/sysadmin log of tasks and events. We will use a Mediawiki wiki to document IOD computer policy and proceedures for ourselves and our user base. We’ll see how it goes.
November 15th, 2005 at 11:15 pm
Shaun,
I found a plugin that would allow editing comments after they are posted. Not sure how good this partictular plugin is but seems like a good feature to implement (if not via this plugin, perhaps another).
http://code.jalenack.com/archives/edit-comments/
November 15th, 2005 at 11:24 pm
Jerry,
About the tabs from the old theme: I agree, they were clunky and confusing. The main reason I put them in there was to be able to distinguish between the “blog” page and the “single post” page. This new theme has an interesting way of making that distinction: It adds a special block to the sidebar containing meta-info about the post.
IMO, I think the Blog/Wiki approach is a great way to keep a running log of articles mixed with an evolving encyclopedia of information. As mentioned before, WordPress uses MediaWiki for its documentation. Other popular sites, like Mac Rumors make use of this hybrid approach with their recently introduced Mac Guides.
Btw, if you or Mason need help with any WordPress issues (like themes, plugins, etc.), I’d be happy to help. I am also curious to learn more about MediaWiki and how well it will works for you.
(I’ve also seen some project sites use WordPress for documentation. This has interesting implications in that users can comment on the posts, but not edit the content. An example site is The Form Assembly, in which the lead developers provide the documentation, and the community can post comments with questions, etc. The similar idea is also implemented in the PHP and MySQL doc pages).
November 15th, 2005 at 11:34 pm
Jerry,
About the plugin: A good find, albeit an unnecessary one… at least for right now.
WordPress already has the functionality for users to edit comments once they are posted, granted the “User Level” (1-10) is high enough. For this blog, all users have a high enough level to edit any comment (not necessarily their own!).
Because this blog contains a controlled community, giving such editting power to our users is okay. If we start adding users with whom we do not have as much trust, we would give them a lower User Level to prevent them the power to edit comments. Thus, perhaps this plugin may be useful later on if our online community keeps growing.
Btw, there are two ways to edit your comment.
1. In the WordPress admin panel >> Manage >> Comments. This lists all comments, and you can find yours and edit it.
2. Simpler, assuming you are logged in and have editting power: At the top of this comments, underneath “srhaber Says”, there is a hyperlink with the text “e” to the right of the timestamp. This link will take you the comment edit form, and should appear for all comments.
November 16th, 2005 at 1:34 am
Perfect. I agree that with such a small community we don’t have to worry much about allowing open editing. The editing features built into WP is all we need for now. However, I looked but couldn’t find where to edit the comments. The ‘e’ to the right of the timestamp you note above isn’t visible to me. I checked the User admin page and it looks like all users, including you and I, have the same access privilidges. So, unless you’re logged in as admin where you can see the ‘e’, something must be wrong with my setup or perhaps my browser. I’m using the latest version of Safari. Any ideas?
November 16th, 2005 at 1:47 am
Jerry,
I did some checking on this… It turns out the ‘e’ link only appears for the user who posted the original entry. That’s why it appeared for me (I was logged in as srhaber, not admin). I naturally assumed it would appear for anybody.
Thus, there’s still the sure way to edit a comment (option #1). And option #2 is available as a convenience to edit comments to your own post.
Alright… time for bed.
November 16th, 2005 at 2:00 am
Nope, I’m afraid that option #1 isn’t available either. I looked and couldn’t find the editing link on the manage page. Must be the same as #2, i.e., only available to the poster.
November 16th, 2005 at 11:26 am
Jerry,
Looks like you stumbled across a bigger issue than I originally thought. You are right, the edit link doesn’t appear in the admin panel page either, except (once again) for comments belonging to your own original post. Doing some searching on the web, it seems like no one has come up with a clean solution (i.e. simple plugin) for this problem.
I’m not a fan of the plugin you found earlier because it relies on verifying users by IP address. It’s functionality seems better geared for an open-community site that allows unregistered users to edit their comments within a given timeframe. What we need here is the ability for registered users to edit their own comments, just like they can edit their own posts.
I wonder how difficult it really is to develop some code that enables editing of a user’s own comment. It may require a hack.
In this case, WordPress at least provides a “clean” way to do hack the core code files. This method implies logging all hacks made to the source code, so that when upgrading to newer versions, the same hacks can be reimplemented with ease.
I’ll investigate further…
November 16th, 2005 at 1:15 pm
Good news: Users can now edit their own comments!
To do this, I hacked the code. Perhaps this could migrate to plugin? For the curious, look in the my-hacks.php file to view the code/documentation for this hack.
It was a pretty simple fix. I already had the comment_id and the user_id values at my disposal. All I really had to do was query the db to check for a match. If positive, then the user owns that comment and should be able to edit/delete it, and the function returns true.
November 16th, 2005 at 3:46 pm
Very cool. We’re almost there. I saw the ‘e’ on my comments, clicked on one, it gave me the edit window and allowed me to change text, but when I went to save or quit, it wouldn’t let me saying that I didn’t have permission to edit the post so I didn’t have permission to edit the comments.
Closer, ever closer.
November 16th, 2005 at 5:06 pm
Wow, what a tenacious little problem… Anyway, it’s fixed (once again)!
Thanks for the catch, and sorry for the tease. The main issue is that there are multiple ways to acquire the comment_ID value, depending on the user’s page/action. I had succeeded in capturing the ID so that the “edit” links and the edit forms appear, but I forgot to test what happens when you actually SUBMIT the comment edit!
Here’s a quick run down on where the comment_ID val comes from:
- Edit Links - from the get_comment_id() function call
- Edit Form - from the query string $_GET[’comment’]
- On submission - from the POST vars: $_POST[’comment_ID’]
Though not everyone may understand the above gibberish, the main point here is: There may still be other places or user-triggered actions that will fail in regards to comment permissions. For example, while editing a comment may work fine for now, I’m not sure if deleting comments will work (it should since it uses the same verification code, but no guarantees).
Thus, all hacks (and plugins, etc.) should always be considered as works-in-progress. The only way to improve a hack is to know where it’s needed.
November 16th, 2005 at 5:28 pm
Final Thoughts
Regarding editing comments, it’s important not to abuse the privilege. The feature should be used mainly to fix typos and to post UPDATED information, but never for a major content overhaul.
I recommend that adding any new content should be posted as a new comment/post, and not as an edit to an existing comment. The exception is if you are posting an UPDATE to a previous comment with info that has since become obsolete. If possible, try not to delete any previously posted content, even if it has become obsolete.
New comments are easily noticeable, as are those tagged with “UPDATES”. However, comment content changes are not easily noticeable, and will most likely be undetected. Furthermore, it is cumbersome for a user to scan the entire thread looking for possible content changes within a comment (typos, etc. are okay).
Thus, when editing a comment, take care to make sure a user can detect your edits. This is best done by appending your edits to the end of the content, and tagged with “UPDATE” or “EDIT”.
Sorry for being redundant.
UPDATE - srh 11/16/05
This is my edit example.