Rather Nasty Problem

There is currently no hook for doing stuff before content is sent to the browser. You could possibly extend wp_setcookie() in /wp-includes/pluggable-functions.php.

The Codex is currently in the middle of Codex Cleanup Week. We are actively soliciting contributions from people like you. In what ways can we better organize the wealth of information, to help you find what you need?

Do please participate.

Let me take some time to go over it constructively, and give some objective feedback. I am a usability engineer, and I might be able to come up with a couple of ideas. I don’t want to just whine, so I want to have some time to evaluate it. Is this weekend too late?

This weekend is certainly not too late – any and all contributions are welcome.
If you want to chat about Codex or any aspect of the docs, then #wordpress-docs on irc.freenode.net is the place to be ??

These are just basic usability comments. Some of them will apply to the actual wiki code, some to the content itself, and some to the structure of the site.

First, let me say that I am fairly new to using a wiki. We use one for our software development, but I haven’t really used one elsewhere. Please forgive me if I don’t have the terminology right, or if I don’t “get” some basic concepts.

I am starting with the main codex page: https://codex.www.ads-software.com/Main_Page

The section headings are pretty clear, but there are too many of them, and they suffer from a fair amount of “functional crossover.” Also, the main heading names are not clickable, even though there are pages that correspond to them. The little arrows after the names are clickable, but the results are inconsistent.

Various sections are laid out in places that may not be immediately obvious. For example, I wanted to find a list of hook calls. There seems to be no immediate link for that in the main page. Fair enough, so I look for a subheading that may contain this list. I assume that “Advanced Topics” may have what I need. Nothing there that fits the bill, but there is a section called “Plugins and Customization.” Maybe that’s where it is. I click on that. It takes me to the “WordPress Plugins and Customization” anchor, on the “Advanced Topics” page. It must be here.

Now, here you have a problem. Almost all of the articles here are about *using* and *finding* plugins and themes. They are not about *writing* them. There’s “Anatomy of a Template Tag,” but that is in the previous anchor, not “Plugins and Customization.” As far as I’m concerned, that is *definitely* a topic for writing a plugin.

However, that’s not the worst of it. Everything is all jumbled together. You need to create a couple of main headings: i.e. using plugins, and writing plugins. You need an architectural overview (there may well be one, but I have yet to find it.)

The long and the short of it is that I had to click all over to find the minimal amount of information I needed to get started writing a plugin. I think that all the information is there, but it is not well indexed. Basically, you need to have an information architect review the entire codex, and organize the information according to a set of use cases. I only represented a very specific one. It is possible that it is already laid out for more common use cases.

There is a lot more, but I thought that this little anecdote would give a good overview of some of the issues as I see them.

(a) It’s absolutely fine to call plugin functions from template files.
(b) What is your brutalization of get_the_content accomplishing that a filter on the_content won’t?
(c) The codex is definitely lacking in developer documentation. But there’s light: some of us are documenting all the filters and will publish the results soon. Maybe check out the other areas and see if they seem to be just as lacking? Part of the issues you pointed out are because of the fuzzy border in wp between users and developers, eg when it comes to using template tags. When they say Advanced, they mean advanced *users*, such as those who want to use conditional tags, rather than just coders.

There is unlikely to be an ‘architecture overview’ anytime soon, but that’s how the cookie crumbles in volunteer projects…

I’m with Firas on (a) and (b). Both should be fine.

And because of that, you can feel free to add a header_start function call, or a do_action(‘header_start’) or something like that, for your own uses. Admittedly, I’m not sure what must go at the start of the header block, unless you didn’t mean <head> but meant PHP header(...);…

-d

The problem with a) is that you need to install filters and themes in conjunction. They must be a set. You also need to activate the filter first from another theme, or you get a PHPuke when you run your theme. (or you need to call the admin system directly.)
b)…hmm… I had thought that add_filter() was a plugin-only thing (couldn’t figure out otherwise from the docs.) If I can do an add_filter() from the theme file, then I can do that.
That being said, why was it that we can’t apply filters and hooks to the “get_” versions again?
The reason for the header thing is that you can’t set a cookie unless it is done before *ALL* connection text. It needs to be done before all other headers are sent. My plugin relies on a cookie.
Thanks for the feedback. I’m really not calling anyone’s baby ugly. WP is a great tool, and I have used it in a couple of blogs. The ugly baby was PHP-Nuke, which I had to practically rewrite from the ground up to get halway decent code.

Just FYI. I did take your advice on b), and wrote the most pathetically basic plugin ever: https://cmarshall.com/misc/paragrapher.zip.

Nice ?? The great thing about making plugins of these things is that you can redistribute the modification, switch your own themes without having to edit templates to apply the modification, etc.