Over the past month or so I’ve been diving deeper into the core of WordPress than I ever have before. Why on earth would I be doing this? I’m working on a new website and my aim is to customize the hell out of it and get it as integrated with a Google Apps setup as I possibly can.
This is proving to be quite the challenge because of the lack of API access I have with only a Standard Google Apps account, and so it’s mostly a bunch of embedding content that I’ve managed to wrangle free of the complex permissions system that Google Apps employs. Don’t get me wrong, I’m glad that I have to jump through so many hoops to get to that content, it means that the data is pretty secure from someone that has no right to view it.
But one thing I have learned repeatedly from my explorations is that WordPress is built from the ground up to allow you to more or less rewrite the entire thing without touching the core code. This also makes it so much easier to make upgrades to the system as a whole without erasing your modifications.
I started off in early January by just modifying the core code, and I had to rewrite a large amount of code (I think that before I started extracting many of these modifications from the core, I had touched 2/3 of all the files in the distribution). Then mid-way through February, I ran into a bit of a snag, WordPress was updated. I couldn’t just upgrade the system because it would erase a month’s worth of work and I would be back to square one. I also didn’t really want to download the code and re-do the modifications, then upgrade from that code set, because I would have to do that every single time a release was made.
So I began the long process of extracting my modifications from the core into plugins, or more precisely, one mammoth plugin that had it all. This was the real journey because I had to learn how to port the same modifications from static code to the plugin architecture that WordPress utilizes. As of now, three weeks later, I have roughly 85% of the job done. And I know how to do most of that last 15%, except for a few special things.
The first is how to force the dashboard to become one-column, and then how to lock it from being changed by the users. With this I also need to be able to remove the dashboard-specific text from the help drop down.
The second is that I need to remove the quick access menu in the header bar, at least conditionally (because the posts functionality is not being used at all and so I don’t need that there).
From what I can find, the first thing isn’t possible without making modifications to the core, and I haven’t researched the second enough to know for sure either way. If, by chance, any of you know how to solve either problem, please let me know either in the comments below or by contacting me.
EDIT: And of course, just hours after posting about this and asking for help, I’ve figured out how to do both things.
The first is a combination of using the ‘user_register’ and ‘profile_update’ hooks to run a function to set the usermeta field for the dashboard layout to be one column and then overriding the admin section styles with the ‘admin_head’ hook to hide the screen options tab.
The second is using the same ‘admin_head’ hook and inserting styles that just remove the help tab all-together (since there’s nothing relevant being shown on any pages).