I'm Nancy, just another WordPress fan.
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)
I've been asking this question for a few months now -- but always in the context of global variables. As someone who's been coding dynamic apps in PHP for several years -- and using other dynamic frameworks since 1996, I should have known better.
The right question was "how does WordPress store transient data?" and the answer now (as of 2.8+) is with the Transients API.
So if you need to set data on one page that's going to be accessed in another, that's the way to do it.
I'm using it with Contact-Form-7 to produce a custom results page. Set a hook on the "before send mail" action:
and then store the data with something like:
You can get the data later and do what you wish...
But finding that API using the "hunt and peck" method in the support forum and the Codex was a bit painful: WordPress Bible BackPress chapter referred to caching. Search of Codex found wp_cache. Search of support forum for that referenced it being obsoleted by the Transients API.
I still may be doing it wrong but it works. [And I can get rid of the solution that used cookies (!).]
Okay don't laugh, but I'm upgrading from 2.1.3 to 3.1.x. And it's a production site, so I want to move the database somewhere to do the upgrade. After the move, I'm getting "You do not have sufficient permissions to access this page" when I try to login as an admin. A variety of tricks (search on that string) didn't work. What finally seems to have been the crux of the problem was that I was changing the table prefix after the move and before I started the upgrade sequence. DON'T DO THAT. At least for 2.1.3, continue with the table prefix of "wp_". Will update if there are future problems, but I expect that bug was squashed sometime since.
Update: There actually doesn't seem to be any support for changing the table prefix of a running installation. The table prefix is embedded in some of the option names (for what may have been a good reason at some point, but it hasn't really been explained well and I don't know what features actually take advantage of this). If changing the table prefix is to be supported a reliable way to find all these options is needed, but doesn't seem to be a priority. See Trac Ticket 4780
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
Okay, sometimes I'm seeing a problem where I
A couple of ways around this:
The 2.9.2 wp_list_bookmarks has no way to access the description of the link category. Here's code to handle that:
/* setup $linkcats array with one element for each category of interest:
array(<category name>,<category description>,<echo>)
It'd be cleaner, I guess, to simply query the database to get that info, but for this quick example I hardcoded things.
*/
foreach ($linkcats as $id=>$info) {
echo '<h3>'.$info[0].'</h3>';
echo '<p class="linkdesc">'.$info[1].'</p>';
$params = 'category_name='.$info[0].'&show_description='.$info[2].'&orderby=order';
$params .= '&echo=0';
$links=wp_list_bookmarks($params);
$links = preg_replace(array('/<li.*<\/h2>/','/<\/ul>\s*<\/li>/'),array(,'</ul>'),$links); //strip off first and last lines
echo $links;
}
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