Posts Tagged ‘wordpress 2.6’

Make way for new Configuration Keys for Securing WordPress

Friday, July 4th, 2008

I thought it was enough to just use the SECRET_KEY constant in WordPress, but they went ahead and deprecated it in WordPress 2.6. That sucks. Really does, because everyone will have to define the new constants to get the advantage, if they even changed it for WordPress 2.5.

The new constants are AUTH_KEY, SECURE_AUTH_KEY, and LOGGED_IN_KEY. I could guess what they are for, but I suppose everyone else can too.

Whatever, just make sure to define them when you upgrade and remove the SECRET_KEY definition in your wp-config.php file. It does appear that they’ve been better named for their handling of authentication and to make sure that if one key is found through clever hacking that it will only affect one part of WordPress and allow the others to function.

This will make WordPress more secure, but also more annoying. Well, initially. Do you know how lazy I am when it comes to editing the wp-config.php file? Pretty damn lazy, but I’m going to do it, as soon as I “svn up” and the new constants are active.

Possibly Related Posts:


WordPress 2.6 and Personal Projects

Monday, April 7th, 2008

It is nice that WordPress 2.6 is not due until August. I was thinking that I would only have a single month for my pet projects, but I’ll have more than two and a half months to finish what I need. I believe with that amount of time, I can polish the patches I made in January and provide better arguments for inclusion into core.

Inline Documentation

Also, the biggest project will be finishing up the inline documentation for WordPress wp-includes folder and the wp-admin/includes folder. There might be functions in other places, as well as adding file level phpdoc documentation to files, but those won’t take very much time. Going forward, I believe it will make sense to document everything else that remains in 2.6, so that developers understand that each new function needs to be documented before it is committed.

Already several core commit team members are adding phpdoc inline documentation to new functions. However, not every core team member is doing so. I believe it will be easier for the community to provide patches for these mistakes, but not everyone is going to care and if care is not taken then a similar problem in earlier versions will appear in later versions.

I don’t want to see, two years from now, many functions which aren’t documented.

I’m thinking I can finish the inline documentation before June, but I would have to work every day, plus weekends to complete everything. It usually takes about 16 hours to document the bigger files, like functions.php, etc, and 8 hours for some of the smaller files. I’m not sure how much time I’ll devote or when I’ll start, but it is something that only has 20 more files to complete in the wp-includes folder, which is the most important to complete. So it would take around 10 days, if I worked 24 hours nonstop, which I’m not going to do. Well, I’m going to have to try for the second week of June for completion. For the wp-admin/includes folder, I’ll have to add another two or three weeks.

I probably won’t be finished with this project until July.

Writing Test Cases

This isn’t part of the WordPress repository, but it does go with it. I’ve stated before that my intentions were always to complete the inline documentation for WordPress and then move on to help write the test cases for WordPress.

The neat thing about writing test cases is that eventually, you’ll come across a bug and will have to write a patch for that bug, or at least seek out bugs that currently exist and write test cases which test whether or not that defect is accurate or not and provide a patch for it.

The goal of this mission, is to clear out most of the defects in Trac and try to make either WordPress 2.6 the most stable it can be, or at least WordPress 2.7 the most stable. It just depends on how long writing the inline documentation will take. Most likely, I’ll only have less than a month to start writing test cases and get patches in, which will put the WordPress 2.6 release somewhere in the beta and RC release stages. Not a good time to start, so at least WordPress 2.7 will get the most patches from the work.

The goal is to write as many test cases as needed for as many functions as possible and writing patches when needed.

Another possible goal is to write test cases for the enhancements, as to whether my patches actually succeed in adding the enhancement. The goal then, will be to get the Trac tickets to less than a hundred with it primarily consisting of enhancements and tasks. However, this is optimist, but really the community as a whole will provide the majority of patches.

The secondary goal is to reduce the overall amount of Trac tickets.

Google Summer of Code

You know, I would really like to be accepted into this program, but I’ll have to finish as many files with inline documentation before I start and it will probably throw off my above timeline. If I’m accepted, I’m going to spend the majority of my time working on whichever project I’m accepted for.

This really means that I’m probably only going to work on the phpdoc on the weekends, but for only a few hours, so it will slow down my timeline for inline documentation, but I still hope to have all of the files in wp-includes finished before WordPress 2.6 is completed. If I’m accepted it will also look like I won’t even get started with writing test cases until the Fall, which will give me a lot of time to devote to writing test cases for both WordPress 2.7 and up towards 2.8.

OTC Spring Semester 2009

If I’m graduating this Spring, then I’ll be going back to school next Spring to start my Internet Application Development degree. I do not plan to be active in the WordPress community at that point. I might come back to write test cases and inline documentation when needed, but if my above projects are completed, then I don’t think there will be a need me any longer.

Therefore, I’m thinking ahead to creating a photo gallery application or joining Zen Gallery project. I also look forward to fixing Mecha Asylum and rejoining the Asylum Futura project and releasing Mecha Asylum as a branch to that project. There are a couple of other game projects that I hope to work on during the school year (which really shouldn’t be difficult, since I’ll already have my core classes finished and would only need to complete the degree classes.

I’m probably looking at three semesters, depending on whether I go for full time or part time. However, I’ll be paying for everything, so I’m pretty sure I’ll only be taking a few classes at a time to not break the bank.

Regardless, I do think I’ll join the WordPress community again in the future, but it probably won’t be until I have gained progress on my other projects, like DragonU.net, AbsidonGames.com (which I want to be able to have repositories for, with Trac and eventually continuous integration), SantosJ.name (not just a blog anymore), and the browser game projects. Well, besides the browser game projects, which take about a three months to develop, the other projects could be worked on and completed throughout the 2008 year.

2008/2009 Plans for Sites

Mostly with DragonU.net and AbsidonGames.com, I want to switch them over to WordPress as the CMS and use it for the pages and designs. That way, I don’t have to write a custom administration panel for the sites and will have everything I need to allow other people to manage the site along side with me. I’ll also be able to write plugins for the rest of the authors and modify the themes. I’m probably going to use my current theme that I bought a few years ago for several months. After that, I’m going to buy a new theme or try to get a new custom theme for both sites.

AbsidonGames.com is a bigger project in that it will require adding Trac support and probably a plugin which allows for adding members of the blog to the Trac and Game Repository System. So everything will be managed by WordPress and who has access to what. It can be done in stages, which it probably will anyway, but I want all of the game sites on my hosting server to use Subversion and not FTP. However, to do so, I need to be able to allow new users to sign in and register automatically.

AbsidonGames.com will provide the news network, so that someone would only need to go to AbsidonGames.com to see what is being developed. Also, the games will grab the RSS feeds for their news section, completely replacing the need to have a news administration panel in the games. There will probably be one anyway, but probably not for adding news, but managing which feeds are added, as well as which news items are shown.

SantosJ.name just needs a photo gallery, my resume (probably just link to linkin along with a printable site version), as well as a picture of myself. I’ll probably also go through all of the articles I’ve written and either expand upon them to create something bigger or tag them. I’ll probably want to extend the Browser Game Development articles I started to write, since they get a lot of traffic.

I keep saying that I’m going to improve these sites, but never seem to get around to doing so. I think also for Absidon Games and DragonU, that the biggest time waster, was the custom CMS that I built. I think going to WordPress will save a lot of time and allow me to focus on just the content and additional features, instead of working from the ground up.

Possibly Related Posts: