Tag Archives: wordpress

Make way for new Configuration Keys for Securing WordPress

Posted by Jacob Santos on July 4, 2008 Comments Off

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:


Documenting the Easy Functions First

Posted by Jacob Santos on June 16, 2008 5 comments

I think my mindset has shifted somewhat. Before it was get as many shorter files as possible out of the way and then focus on the files which have the most functions in them. I’m thinking this isn’t the best way to go about writing the inline documentation.

Mostly, the inline documentation for post.php is incorrect. Some parts are horrible and completely inaccurate. That said, most of the functions are documented, albeit inaccurately. It begs the question whether it is better to have poorly written documentation, than no documentation at all. It isn’t something I can answer, because if the answer is no, then I really shouldn’t be writing inline documentation or any documentation for that matter.

The goal is to have inline documentation which is as accurate as possible and as reflective of the code as possible. I think practice makes perfect, but I still have a long way to go.

I documented about half of the functions in functions.php (some of the total was from documentation that was already there, or added by someone else). There are still some functions which are short in the amount of lines of code. Those functions could do with a descriptive short description header with the parameters and return type documented. Not hard work at all.

That said, by the time those functions are finished, most of the file is finished and it shouldn’t be that difficult to finish the file off. Completing functions.php and formatting.php would be a huge benefit towards the inline documentation effort. Many of the functions plugin and them authors will use will be found in those two files. The post.php file and/or post-template.php file also contains a lot of functions within.

I think my goal now has shifted to completing the files which are almost complete. Still have to finish category.php, but that can wait. I think fixing post.php and finishing it will also be helpful for those writing themes and plugins. It is coming down to what is left is what most plugin and theme authors use the most. This should be a huge turning point towards the quality of documentation.

The next step after the inline documentation is finished is to turn towards the codex and translate the geek speak to non-technical explanations and examples to help theme and plugin authors further. For me, that will probably come during Spring of 2009. If I can finish up the inline documentation for Summer of 2008, then I’ll be working on a few other projects for the Fall.

Possibly Related Posts:


First Day of WordPress Documentation

Posted by Jacob Santos on May 15, 2008 Comments Off

Well, I’m a few days late with working on the WordPress Documentation. However, I was able to create the repositories I need and converted all of the current documentation to a new Trunk checkout. I’m going to start working more on it later.

I just realized that the project I had for finding all of the WordPress function versions needs to be restarted once more. I need to totally work more on this to make sure that it is done right and that the code is parsed correctly. I’ll rewrite the parser to output XML and then pass over that to get the functions and what not.

I plan on implementing a couple of other features, such as tracking when parameters were added and removed and what version. I also want to track hooks, when they were added, which files, and when/if they were removed. I hope to create a one stop shop for all of the current code tools out there with a bit more reliability.

I also want to take hold and try a Subversion checkout approach, which does everything automatically also. That would be the best bet and try to do something which switches the checkout when a new version comes out.

This will take away from writing documentation, but I’ve been putting this off for a while now and it needs to be done.

Possibly Related Posts:


WordPress Controller Design Overview

Posted by Jacob Santos on May 14, 2008 Comments Off

I’ve been thinking about this and I really do think that the code could be improved for the Model-View-Controller implementation. My focus is more on the model and view and not the model however. There is code which exists in different files, which I would like to combine in some areas and split up in others. Some areas do things that it probably shouldn’t be required to do.

Rewrite Component

The rewrite component tries to find, or query what controller is needed to be run. The difficult parts are figuring out what method is being used. Is the page being accessed using URL query vars, or for example index.php?p=## is it the path info method (index.php?/2007/10/5/1) or finally is it the mod rewrite method or permalinks.

It is highly possible that the code might be an combination of the query vars and permalinks. The rewrite module must enable the plugin or code to transform their code to use one or the other. It still must support query vars along with path info or permalinks.

There will be several support classes along with the Rewrite Component. The first will determine whether or not mod_rewrite is even enabled (probably use an option like now). Another component to test each of the methods described above and return the one that makes the most sense. Finally, the last support class will extract the URL useful information based on the query vars and, or URL path.

The main component class will be the WordPress_Rewrite class, which will be used to push to the controller to handle the code.

Mod_Rewrite Component

This component, I want to seriously overhaul to simplify the code base and try out some fluid interface design. It will most likely use most of the same code, but split up into multiple classes.

Controller Component

Ah, the catch with this is that the Controller just needs to be an object or function, which loads the correct template or plugin file. So I mean, you could very well say that the Rewrite class is the controller, but the hook or object will be expected and run.

Possibly Related Posts:


Thirteen days of Writing WordPress Inline Documentation

Posted by Jacob Santos on May 10, 2008 Comments Off

My original intention was that after school I would write inline documentation for WordPress, while going back over old patches I made and update them for 2.6. The problem I see with that is I might be spending more time trying to get the patches in to the core then I would be writing inline documentation.

I believe that if I succeed with my intention that all of the wp-includes will be documented for WordPress 2.6. Which will be great, but I also plan on having repositories for creating patches for the 2.5 branch and for the 2.3 branch for the inline documentation. At some point I’ll create a patch which documents all of the files for the 2.0 branch, but I’m still undecided.

  1. Tuesday, the 13th of May
    1. Update current trunk repository and fix any conflicts.
    2. Create two new repositories for the 2.5 and 2.3 branches.
    3. If time, start fixing known documentation issues and go over current documentation in all files.
  2. Wednesday, the 14th of May

    Fix known documentation issues and go over current documentation in all files.

  3. Thursday, the 15th of May

    Document user.php, and start query.php documentation in the wp-includes folder.

  4. Friday, the 16th of May

    I have surgery this day, so I might be a little out of it, but if I’m semi aware of my surroundings and feel up for it, I will try to document cron.php and finish documentation for wpdb.php. Also, if during the check over the old files, if any previously completed files have undocumented functions, then to document them also.

  5. Saturday, the 17th of May

    Depending on the pain, I’ll document category.php and start comment.php.

  6. Sunday, the 18th of May

    Finish both query.php and comment.php documentation.

  7. Monday, the 19th of May

    Start functions.php documentation.

  8. Tuesday, the 20th of May

    Continue working on functions.php documentation.

  9. Wednesday, the 21th of May

    Finish functions.php documentation.

  10. Thursday, the 22th of May

    Finish post.php documentation.

  11. Friday, the 23th of May

    Start formatting.php documentation.

  12. Saturday, the 24th of May

    Continue working on formatting.php documentation.

  13. Sunday, the 25th of May

    Finish working on formatting.php documentation and functions.php, if there are still functions to document.

  14. Monday, the 26th of May

    Create file level documentation for all base directory files describing the intention of those files, as well as all other php files. Document shortcodes.php as well.

Files that will hopefully be documented

  1. user.php
  2. query.php
  3. cron.php
  4. wp-db.php
  5. category.php
  6. comment.php
  7. functions.php
  8. post.php
  9. formatting.php
  10. shortcodes.php

Files that will be left to document

These files I plan on documenting on the weekend during the Google Summer of Code, depending on when it starts. If it starts later than the 26th of May, then I plan on continuing documenting files on this list.

  1. capabilities.php
  2. category-template.php
  3. classes.php
  4. feed.php
  5. general-template.php
  6. link-template.php
  7. post-template.php
  8. script-loader.php
  9. theme.php
  10. widgets.php

Planning is never perfect

If I can fully document functions.php and formatting.php, then I think I would have done a good job during this 13 days. Those two files take up a major portion of the total WordPress library and getting them out of the way will allow for quicker turn over for some of the files with less functions in them.

My plans on to work on this roadmap and if I have extra time to pull from some of the files with less functions in them. I believe I can document 13 functions for every 5 hours, so some of the files will overlap on some days, but I’ll probably be able to get out two files in one day.

Out of the list that needs to be completed, I won’t be documenting classes.php and widgets until the very end. I’ll focus on the files which have a short list of functions to document. That way, the list will be down to about three or four files which have a longer list of functions to document.

WordPress Admin Includes directory

Once the wp-includes folder is completed, the wp-admin/includes directory needs to be documented. This directory has a shorter list of files and functions, so it won’t take as long. However, I’m not going to focus on it, until after all of the files in wp-includes is finished.

What happened to documenting everything

Truthfully, I’m trying to document all of the files, but reality probably won’t prevent me. I’ll be lucky to complete the files on the list, but I’m going to at least try.

Possibly Related Posts:


Why Write a WordPress User or Developer Manual

Posted by Jacob Santos on May 8, 2008 Comments Off

What is DocBook and the Advantages?

DocBook is an XML format, which allows for creating documents independent of any one presentational format, like for example (X)HTML or PDF. The focus is on the content and the fifth revision of the format allows for a lot more freedom for mixing XML namespaces, so it is possible to mix in XHTML when desired.

However, the advantage of writing in the DocBook format, is that it allows for easier translation. They only need to focus on the content between the DocBook XML tags and can easily convert the DocBook to XHTML or a PDF from that one format.

The other advantage is that with the latest revision of the standard has a project that works with DocBook, which allows for displaying the DocBook in XHTML format to see what the final product will be. Aside from the XSL project, I’ve found that converting to other formats are quite a bit more involved.

What is an User and Developer Manual?

The User and Developer Manual concept is very simple: you want the very brief, basic information to give to the user on every aspect of the application. Sure, it won’t be able to walk them through every possible use case, like the WordPress Codex would. Sometimes, you only need to shove the user in the right direction and the user will be able to figure the rest on their own.

That is the concept should allow for some what quick turn out when there is a new release, once the finish product is complete for the first time. Between each release, how much really changes? A few things sure, but the user functionality largely remains the same. Therefore, once the manual is complete for one version, you can just update the pieces that changed and add new sections on new features that were added and release the updated manual for that version.

So you would always have a manual for that version. When you compile the XHTML site and/or the PDF for that WordPress version, you can always release that version. When the next version comes out, you can just release a new XHTML site and/or PDF for that version. So, you would have both versions available for those who are slow to update but still want information on the older version.

The Hard Part

The hard part is filling the User and Developer Manual with content the first time. Also, if there is a major overhaul, then it will mean that major portions of the document will become obsolete and need to be rewritten.

However, I think that if such an effort were made, then it would have some merit to charge for such a document. Whether anyone would buy such a product is yet to be decided. I think in the spirit of WordPress, it should be free as the software is, but I find motivation for such a long and tedious project hard to come by when everything is done for free.

My Goal

I still plan on creating the User Manual, because I still need to do research on DocBook format and become competent in the format, so that when I need to use it for my projects, I have experience on what doesn’t work, what does work, and what the visual output will be while the document is being written. Also, I need to learn how to change the layout and design of the DocBook output, using either the XSL and PDF.

I want to learn how to create both the XHTML site and PDF and writing the WordPress User Manual will allow for enough motivation to actually accomplish that goal. If I can find enough people to continue the project or help out, then I’ll have the manual as completely free and GPL. Well, it will be GPL anyway, but I might decide to charge for the PDF.

Content

The content will consist of text (of course), pictures, and video. Going over the video capture software, I think it will be quicker, faster, and somewhat easier to build the entire manual in multiple screencasts and then use that material to create the content in the User Manual. People will value the Videos and of course the search engines will pick up the content and pictures.

I want to put all of my raw content out there for anyone to use, so that when I leave the WordPress community, someone can reuse the content to take off where I left off. I also want to give the RAW video feeds, so that someone who has a better voice or speaking ability can do a better screencast based off of my videos.

It will be a nice experiment and I look forward to it. However, I’m thinking it will be a Fall project. The Developer Manual portion is a lot more involved, so it will be free, based in parts off the WordPress Codex, and be GPL. I want to have every component in WordPress detailed in the manual and it probably will be a lot more focused with examples and more content.

I’m more torn on the Developer Manual, because the purpose will be more geared towards allowing ease of translation than anything. It belongs on the WordPress Codex sure and I’ll probably build the majority of content on there before converting it to DocBook. I’m thinking of using the WordPress Codex as the planning and organization of the DocBook, before I compile the content into the DocBook format.

Possibly Related Posts:


Summer Schedule

Posted by Jacob Santos on May 1, 2008 Comments Off

School Graduation/Finals

I’m taking the Finals the May 13th, so after that I’m done with school, as long as I pass all of my classes with at least a C or better. I may not pass one class, because I’ve been tardy everyday and there was this requirement of doing labs and I’m pretty sure I’ve haven’t done most of them, which is going to screw me up pretty bad.

I’ll just take it and see where it goes. It is a take home final, so it will be interesting. I did well with the presentation and paper and that is huge portion of the grade in the class. I’m hoping I do well enough with the final that it makes up for the labs and tardiness.

The math class I’m totally passing, probably get a C, even if I don’t show up for the Final. I’m kidding, but it should be pretty easy to get an ‘A’ in the class. However, the class is not important to graduating and isn’t an requirement. I could fail the class and pass the other two and still graduate. It is a requirement for another class I wish to take next year.

I’m pretty sure I’ll be passing the Physics class, which I just have to pass the Final with a high enough grade and that is not less than a ‘D’. I have to turn in the rest of the Labs, which is done, but just needs to be printed, organized, and put in the folder. I might have one or two missing, but overall, it shouldn’t affect my grade that much.

There is also one more Lab Test, but I’ve been doing very well with those, so I’m not worried. So an B+ or A on the Lab Test, mostly ‘A’s on the labs reports, and hopefully a ‘C’ or above on the Final will allow me to pass that class. If I can pass this class, it will lower the amount of credits I will need to get an Internet Application Development Associates of Applied Science.

WordPress Inline Documentation

Between May 13th to the start of the WordPress Summer of Code, I plan on working on the WordPress Inline Documentation every day or at least try to. If I can work on the inline documentation every day, then I should be able to complete most of the inline documentation, if not all of it by the time the WordPress Summer of Code formally starts.

However, in the highly probable event that I don’t complete the inline documentation, then I do have plans to work on it on the weekends during the time I’m doing the WordPress Summer of Code.

The files in the wp-admin folder also need to be documented, for those hacking the core of WordPress in the future, who need to figure out how to fix bugs.

Past WordPress Patches

I have patches which exist out in the WordPress Trac. I think this time from May 14th to May 28th-ish, I want to go over the past patches I created and polish them to get them ready to complain about how they aren’t in the core and how I would very much like to have them in the core and how they will benefit others if they were in core and not just myself (whom won’t benefit at all from them being in the core once they are in core).

WordPress Summer of Code 2008

Somehow, my project was accepted, so I’m going to be working on providing a means to easily benchmarking WordPress with the use of a plugin. The project also involves other areas of WordPress, but the primary focus will be completing the plugin to make it easy to figure out which parts of WordPress or WordPress Plugins need to be optimized.

Possibly Related Posts:


The WordPress Community

Posted by Jacob Santos on May 1, 2008 Comments Off

When people speak of the WordPress Community in high regard it is for good reason. The WordPress community holds within its group some of the brightest, talented, educated, and motivated members. It isn’t all hugs, but you have problems within any community open sourced group. However, what I see is some of the best discussions and involvement from the members.

When I joined the WordPress community August of 2007, I entered with very low expectations. As a developer, I’ve heard many terrible things about the code base, so I partially blamed the community, since I figured it would be up to them to ensure code quality. How wrong I was, from the beginnings of partial debates about the merits of Swift Mailer and HTML Purifier to accusations that those debates were really about converting WordPress over to PHP5 (hint: they weren’t).

I hold that no argument is worthless, if it doesn’t degrade to a flame war. Hey, not everyone is correct all the time and unless someone brings up facts that pull you to the truth then you’re not going to change your stance. This is partially why those outside the WordPress community, who look only at the code think poorly of WordPress.

It is interesting, but you can see who the best members are from their discussions, viewpoints, and understanding of not only WordPress, but also of programming and other fields which complement it. I’ve learned more during the 8 months while on the WordPress Hackers mailing list, than I have during 2 years of self motivated development.

It is interesting however, you get more out of WordPress becoming a member of the community, whether on the forums, blogosphere, or on one of the mailing lists. I can see why Lorelle holds each member in such high regards. These people are a small percentage of what makes WordPress what it is, but they do a lot more to gain the trust of others. By focusing on the interactions of these members, it might be enough to move someone who otherwise wouldn’t be motivated to get involve with WordPress to do something.

However, I take each and every discussion I’ve had in the past and will have in the future with those on the mailing list with appreciation and respect. I might not always have a tone that shows it, but it is difficult to say, “I love you guys” online and sound sincere.

I would say that all WordPress has to do is pull its head out of its ass and start coding in a fashion which ensures quality, but they’ve already been doing so. It may take a while, but WordPress already has the community, high adoption rate, and all it needs is a good reputation of professional programmers who know what they are doing. One day, it will be nonsense to say that the code base of WordPress is crap and I’m going to be happy when that day comes.

Possibly Related Posts:


Response to Mark Jaquith’s Answer

Posted by Jacob Santos on April 27, 2008 4 comments

This was answered on the Testing WordPress Presentation and my response to Mark’s comments.

The first part of Mark’s answer is correct, you don’t want to put enhancements and new features in point releases that usually only have a month before release. You can’t test the enhancement or feature well enough in that time frame to fix all of the issues. Usually what will happen is that a ticket will be posted at a point release and then have to be moved back to trunk milestone.

Also, all fixes will be applied to Trunk first and then back ported to the releases it needs to be. So a developer patching the software needs to not only patch Trunk, but also the previous versions the bug affects. This also includes 2.0.x for security issues and defects that relate to features within the 2.0 branch.

However, the second part is incorrect to a degree. Patches are committed, but only the ones that the core developers care about it seems. I created patches for those tickets that no one seemed to care about and it also seems that the core developers also don’t care about them either, because for some of them, they’ve yet to commit my fixes.

When I stated earlier that I had mix feelings when writing the How to Patch the WordPress Core, it is because I had to almost beg to get patches that I know fixed issues committed to the core. Hell, someone fixed an issue with the PHP 5.1/5.2 default timezone, and it still hasn’t been committed. If it has already been committed since I’ve last looked, it would have taken almost 5 months, before it was committed.

It doesn’t make sense to me that you’ll create a patch for a feature way way before the feature freeze and then when the feature freeze comes, “Oh yeah, feature freeze sending to the next milestone.” Oh yeah, it has a patch, why didn’t you commit it sooner? It makes me really angry and I have trouble caring about creating patches based on the assumption that even if I write a patch, it has a high probability of not being committed without informing the core developers that it exists and have to argue and debate why it should go in.

It is one reason I like the Automattic WordPress Tests, I’ll finally be able to prove that my patch fixes the defect, which will mean that it will push my patches in quicker. At least that is the hope, whether that is the case is up to the core developers.

If you ever woke up, thought about writing a patch for a WordPress ticket, and thought, “What is the point? It probably won’t be committed anyway.” That was me, but I kept with it. If you think about it, there were others that came up to the same barrier of entry, which the core developers blocked and those developers say, “Screw WordPress, I’m going to work on a web application that actually understands the professional paradigms of software development.”

If the intention was always, “Thanks, lets commit this patch right away.” Then perhaps it would be possible that WordPress would already have full inline documentation today.

I think that it is just my level of fixes and what I’m interested in that the core developers either don’t understand enough of the problem to realize that my patch fixes the issue or that they don’t care about my issues enough to actually commit them as quickly as others.

You’re level of happiness in creating patches for WordPress will differ. My level is just about depleted and I almost don’t have any rationalization to continue creating patches. My focus now is inline documentation, writing test cases, and hopefully the Google Summer of Code project, which has a better chance of creating patches that will actually be committed.

After that, I’m done with WordPress, not that WordPress needs me, but if they continue to have their attitude, then they will eventually lose other developers that want to create patches, but also get blocked by the core developers lack of interest in the ticket. I don’t patches to have them just sit there for weeks or months. I create patches for problems I care about and I expect them to be committed as quickly as possible or at the very least provide feedback on why the patch won’t be committed.

If it is said that the patch is unacceptable and why, then that will go a long way with the relationship. I can accept that my code sucks and how I can improve it. I can’t accept not saying anything and just not committing the patch and allowing it to become stale.

The only patches I didn’t have problems with were the patches that added inline documentation, so those are the patches I’m going to create. Alex also seems to commit patches to the Automattic WordPress Tests in a reasonable amount of time, so that is also good. I wish there was a Trac for that or at least a component on the WordPress Trac for archiving patches, tickets and who created the patch.

Possibly Related Posts:


A WordPress PHP Extension

Posted by Jacob Santos on April 22, 2008 Comments Off

I’ve been playing around with this idea for a while and I think it would be very interesting concept to complete. The concept is simple and most of the code will be easy. The concept part is take what is most often used and least optimized and rewrite it in C/C++. The easy part is that you can sort of do similar coding structure, albeit with pointers and zvals, but the code can be structured in the same way, well mostly.

The disadvantage of taking an almost 1:1 approach from PHP to C/C++ is that the result code may only be slightly faster (between 15% to 30% increase of performance). Comparable, it might be even faster to instead use C and C++ to the full advantage and use algorithms based completely on them.

However, it would be interesting to enable the Plugin API to execute in linear time with some of the logic. The Plugin API would be a really great first testament of the PHP Extension and it would be interesting to implement other features within it. However, I think just having every function within C/C++ would be a good initial effort.

The initial release has to be released quickly, be optimized as much as possible. If you don’t optimize the C code as well, then you can have just as bad performance. It should be fun, but I hope that I’ll have the fortitude to actually finish the plugin API part to enable benchmarking between the PHP and PHP Extension.

Possibly Related Posts: