Cool deal. Glad to see you are getting started.

There are basically only a few things we use class or style wise.

All the headers. Like ‘Usage’, ‘Description’, etc we use the Heading 3 setting. That way they are red in color. We rarely use Bold or the other heading sizes.

For the actual usage and code examples we use the code highlite function.

You put the cursor where you want the code to be placed.

When using the visual editor… Click on highlighter, select php, enter or paste the code in and click save.

This will format the code with color highlites. You won’t see the actual style until you publish and view on the page itself.

Looks like we need a little style formatting adjustments here for an uploaded video. If you click on the actual mp4 link at the bottom of that post you can view the video properly.

And don’t get me started on the small image setting and align left that they use here.

Also @steve & Andy. Notice, in the video, the entry box when using the highlighter overlaps the submit/cancel buttons. I don’t know if that plugin is up to date. If so we may need to hit it with a little CSS.

I will go take a look at the entry in a little while after I clear the forum this morning and walk the dogs.

As a quick response before looking at detail – if you need any more CSS classes defined then let’s do it as there is nothing worse than putting in-line formatting in documents using style attributes which then have to be manually changed and edited when you want to redesign things. And there is talk of re-working the codex to fit our newer style and to make it responsive.

So anything you need or anything you find that is missing all you need to do is shout.

The next bit is both very annoying and a little amusing. It is a shame you chose sp_write_error()  to start with because that has actually changed in the next version to have 2 new parameters…

And I am really very sorry about that. Just one of those things.

It now is:

sp_write_error($errortype, $errortext, $errno, $keyCheck)

where $errno speaks for itself and $keyCheck is a kind of short string based on the error that is used to check if there is already the same error in the log and if so does not write it out again.

This means also, of course, that the two calls to the function supply those values.

I’d like to use description-list HTML tags (dl, dt, dd) for defining the parameters.  Since I’m assuming we’d mainly use these tags for documenting function parameters and the like, it would be nice to have the dt style font be similar to the font used by the syntax highlighter (courier or something similar).

On the issue of the new release having 4 parameters instead of 2, this brings up another point:  where should the information go about the 2-parameter version being in releases before 5.3?    The WP codex would put this information in the Change Log section.  Is this where you folks would put it as well?  

@Andy, I’m not quite clear what you mean by “…the two calls to the function supply those values.”  What 2 calls are you referring to?   And if any existing custom code uses the 2-parameter version, does the function have default values that it supplies for the 2 new parameters?  

Natalya Murphy said
I’d like to use description-list HTML tags (dl, dt, dd) for defining the parameters.  Since I’m assuming we’d mainly use these tags for documenting function parameters and the like, it would be nice to have the dt style font be similar to the font used by the syntax highlighter (courier or something similar).

I will take a look at the CSS in a little while. I donlt even recall which css file we are ysing there now believe it or not!

On the issue of the new release having 4 parameters instead of 2, this brings up another point:  where should the information go about the 2-parameter version being in releases before 5.3?    The WP codex would put this information in the Change Log section.  Is this where you folks would put it as well?  

I am all for starting a change log section when required. It really is the only way to do it.

@Andy, I’m not quite clear what you mean by “…the two calls to the function supply those values.”  What 2 calls are you referring to?   And if any existing custom code uses the 2-parameter version, does the function have default values that it supplies for the 2 new parameters?  

OK – there are two current calls with SP to the sp_write_error() function – both of then in the same error api file. These too have been updated to pass in the two new parameters.

Now, I think the chances that anyone outside of us has used any of these currently undocumented functions is a big fat zero. But … you are of course absolutely right that this should not be taken for granted. So yes – I have changed the code to allow for these parameters to be optional and have default values if not passed.

the css file for the codex site has been updated with some styles for description list tags…

Also note it is just an initial stab at some CSS for this. I have not been able to try it in that environment yet – will try today. Need to see some use before we perhaps hone it to what we might want.

I don’t notice any changes on the sp_write_error styles.  I used the dl/dt/dd tags in the parameters section and the entry names still appear in a sans-serif font

your codex entry for the error api is definitely picking up the new description list styles… but I dont see that Andy changed the font at alll in them…   so its still using the CabinRegular font from the content…

so not sure that he caught a desire for a specific font…

Mr Papa said
your codex entry for the error api is definitely picking up the new description list styles… but I dont see that Andy changed the font at alll in them…   so its still using the CabinRegular font from the content…

so not sure that he caught a desire for a specific font…

Andy,

Can you set the style for dt to use something courier-like to match the syntax highlighter style?

I did. It now uses the same font being used by the code sections in the codex.