Codex tools: Log in / create account
I'm Nancy, just another WordPress fan, wpforum AT sgtst.com.
I've been working with WordPress since March 2005, and have put up about a dozen sites. I'm looking at WordPress mainly as a content management system for small (even all-volunteer) nonprofit groups.
I'm beginning to think I understand some of what's going on and would like to help out where I can.
I've recently celebrated my 25th anniversary in the open source community. I started as a sysadmin for a 4.1C BSD installation for a small research group and continued in that world for about 15 years. I then migrated to consulting for customers of a company doing web based applications, and have been consulting on my own for about five years.
I'm a member of NTEN, ACM, and AAUW.
Converting2wp 01:59, 14 May 2007 (UTC)
Okay, I'm a convert. I'll switch all my sites to 2.7 as quickly as possible. Thanks to all who made these changes happen.
Rearranging directory structure While the new system to allow moving wp-content to a different part of the file system tree is nice as far as upgrades go, it took too much time trouble shooting plugins that didn't grok the new structure. I'll pass for awhile.
I've heard tales of upgrades losing categories, etc. I don't think all these steps are really necessary, but here's an article on upgrading one minor version at a time (2.0 to 2.6).
I'm converting change.bbvx.org from WordPress 2.0.7 to 2.3.1. This is the story of bumps in the road: User:Converting2wp/Upgrade saga This is done by creating a test environment for the upgrade.
I'm still a bit flummoxed by one of the recent upgrades, where someone said (in the support forums, I think)-- "it's only a very few files".... Well, for those of us thinking about upgrading production sites even a few files, coupled with several plugins can be a major task. Upgrade from 2.3.2 to 2.5.1
My life has gotten easier since I've started using Subversion to manage plugins and files. For the themes, it means I've got an easy safety net for hacking at the changes. For plugins, it gives me a way to move plugins from one installation to another with some degree of sanity -- creating a collection of plugins that all work with one version of WordPress. I'm still not sure about how to control mods to the core files that the plugins require. Draft: User:Converting2wp/Subversion
Is there a way to combine various threads discussing the shortcomings of the current server-side implementation of WYSIWYG editing and the workarounds folks are using to give people a more comprehensive introduction to the topic?
See my WYSIWYG page for discussion
At least some new users need an FTP tutorial. Is there one we can link to?
Here's a piece it's taken me about a day to figure out. It relates to using WordPress as a CMS, and would probably best fit on Pages. See a more compact suggestion on Talk:Pages.
If you're making extensive use of Pages in WordPress, you are probably using a hierarchical structure of pages and are using "permalinks" so that you'll have pages like recipes/chicken/roast-chicken-with-rosemary/, about/chapters/ma/boston/, or whatever. There will come a time when you want to link from one page to another. This will go much more smoothly if you remember that WordPress-generated links always represent a page's address with a trailing slash. Remember to put that trailing slash in your manually generated links. Remember, too, that relative links on a page will behave as if the actual name of the page were the/directory/structure/index.htm. That means if you want to put a link to "Roast Chicken with Lemons" on your "Roast Chicken with Rosemary" page, you need to code the link as
href="../roast-chicken-with-lemons/" Don't forget the trailing slash!
Though the two roast-chicken recipes may look like "siblings" in the chicken directory (and so you might want to link to just href="roast-chicken-with-lemons/") they aren't. They are really much more like
and
hence the "../" to get up to the "chicken" directory before tacking on the "roast-chicken-with-lemons/".
What happens if you forget the trailing slash, you ask? Well, then when someone navigates to the page from your link, it will be treated as, for instance
and then the link to the "with lemons" recipe won't work any more: ../roast-chicken-with-lemons/ will now mean
There are some search terms ("CMS" comes to mind) that are shorter than the default 4 characters that MediaWiki considers significant. I looked at the options and can't find a way to add words less than four letters into the system so that they could be found. Changing the system defaults so that all three letter words (but for those on the stop list) would be found seems overkill. Perhaps this could be addressed by making sure that any key word of fewer than four letters is also expanded into another common search string? Are there others like CMS that are candidates here? Could they be mentioned in the help?
8/18/07: Okay, maybe something as simple as a reminder that Google still works: "CMS site:wordpress.org" as the search string.
I'd suggest adding a note about the effect moving WordPress (in particular the default wp-content/uploads directory) has on the guid's of attachments. to the page Giving WordPress Its Own Directory. See support discussion. Would it be worth it to consider making it a recommended practice to have the "uploads" directory outside of the WordPress main directory? It seems to be a different enough in its requirements for backups and such that this separation would be helpful. I'll be doing it that way for my future installs, but would be interested in others' comments.
For some sites, contributors may be board members or other volunteers who don't really even need to know this is WordPress. They just need some orientation on how to move around the editing subpanel, when to use pages and when to use posts, how categories work, etc. Once upon a time, the STC -Suncoast Chapter had a screencast video of editing a post. That might be too hard to keep up to date, but a "user friendly" discussion of posting might be helpful. I've written a sample for a recent client. Let me know if you want the link.
There are places where the Codex says a file must be 666 or a directory 777 (and I think I even remember seeiing a directory 666 which makes no sense). It might be good to provide documentation on what the tradeoffs are for these and why 644 or 755 might be just fine in certain hosting environments.
My life supporting multiple WordPress installations got a lot easier when I started putting the plugins and themes into a subversion repository. I'm not sure I've got the best practices nailed down yet, but I might be able to give out some tips.
The page get_the_title is marked in need of editing. It has a breadcrumbs example that would I think be useful. I'm using it for page submenus that might better be converted to breadcrumbs.
Related to the above, the page Dynamic Menu Highlighting is marked in need of editing (5/27/07). I'm not exactly sure what the questions are, but if I get to the page above, I'll try to look at that as well.
When uploading a file of a type that's not in the allowed list, the error message is "File type does not meet security guidelines".
The allowed list is defined in wp-includes/functions-post.php.
Info on plugins to handle this more gracefully (in current WP releases?) [1]
We might be limiting the contributors we get to those who are already somewhat familiar with MediaWiki (or at least wikis in general).
The reason I say that is that I think a logical path for new users is Community Portal > How to Contribute > create a new User Page. They then see, under the heading "First Steps", step #1: Click on the Discussion Tab at the top of this page.
But they're a new user. There is no "Discussion Tab" at the top because they are still using the default (Codex) skin. In fact, I couldn't find a "discussion" link anywhere on the page until I logged in, found the "preferences" section and changed my "skin" to Monobook. If this is someone's first experience with MediaWiki, I expect that would be a serious barrier to joining the team of contributors.
Should the documentation be changed so that folks do start with the User page and then get guided into what can be done with the wiki settings? Or is this a problem with the Codex skin?
5/26/07: Made edits to Creating a User Page to address this. 5/31/07: This seems to be acceptable to folks