I’m wondering if someone can write an extension (or point me in the right direction) to duplicate the following automatically:

1) Go to “Admin > Weblog Administration > Field Groups > Custom Fields”
2) Edit one of the custom fields of your choosing. Make sure the field is in use in at least one weblog so you can see the results on the Publish page. Also, this is not destructive. :)
3) Paste the following code to the end of your instructions field, replacing the string “FIELDNAME” with the single-word Field Name for that custom field:

4) Save the changes, and open up a Publish page that will use that custom field.

For those who’d rather not “try this at home”, this simply utilizes the Field Instructions for a custom field to place a read-only text input field populated by the Field Name surrounded by squiggly brackets next to that custom field on the Publish page. ;)

In plain English, it lets you copy the code for that custom field right from the Publish page (instead of having to go back to “Admin > Weblog Administration > Field Groups > Custom Fields” to recall what the short name was) for use in Templates. :)

The extension would obviously use its own container instead of piggybacking the Instructions field like I did here. It would also automatically retrieve the Field Name to display.

This is kind of an odd usage for an extension.  Why not write some simple PHP that queries for the fields that exist and then uses the query data to then update each field’s instructions column with the stuff you have there?  Then just run it within a template once and call it good.

Jamie

Because I thought that this was what extensions were for - slight modifications to the backend. Besides, an extension would allow me to keep on reapplying this modification without too much hassle when I upgrade to new versions.

And what do you mean by “run it within a template” - I presume you’re not talking about the regular templates that the CP has a tab for, right?

KKCJ,

Extensions are for modifying CP behavior as well as inserting code into an EE function without requiring a hack.

There isn’t really a hook anywhere that is in a spot that will make it completely easy to automate what you want.  And I guess I don’t quite see why this is something you need to be an ongoing constant change.  Do you plan to add fields so often that running a piece of code once or twice that does this is going to be a problem?

And I did mean within a normal EE template.  EE templates can run PHP code (if you enable it in their preferences).  Its an easy way to write and run a short snippet of PHP while having access to the EE classes that does not require going through the trouble of writing a full Extension or Plugin.

I have cases where I’ll do stuff similar to this and instead of writing up a whole extension I’ll just put the basic code into a template, visit the template (which runs the code).  And then turn off access to the template until I need to run that code again.

If I’m understanding you, you simply want the Instructions to contain the {field_name} in an inactive text field so you can easy cut and paste while developing correct?

I usually only add fields in large chunks.  So it wouldn’t be that bad to add my fields.  Then visit my template with the code that will create and add the instructions stuff and then continue on with my work.

If you really need these to be an extension your best bet will probably be to use the publish_form_headers hook and write some Javascript that will look through the fields and insert the instruction text on the fly.

Jamie

Development of a template to display weblog content is never really over (unless the weblog just holds static data), therefore a PHP script that returns a list of the available fields for a given weblog (if I understand your suggestion correctly) seems to be overkill to me.

For example, say I have a Press Releases section for a company, with excerpt, body, etc. It’s all templated and up & running, but a few months down the line, the company wants to put up a press release with, say, an image. A new custom field is needed for this, so I create it in the Press Release field group. Then I go to the weblog, post the new press release with its image (so I have something to work with), and move along to the template to code in the image placement. But now I’ve forgotten exactly what short-name I used for that image field… was it pr-image, pr-photo, pr-pic? If I had had the short-name displayed right there in the weblog publish page, I might have remembered.

However, now that I think of it, perhaps there’s a much better way to go about this. Would there be some sort of way to have a dynamically generated multi-tiered list (with collapsible/expandable list items) of custom fields available right there in the template page? The initial display would be a list of all the weblogs on the site. When one clicked on a weblog, beneath it would appear a sub-list of its associated standard (title, date fields, etc) and custom fields. Clicking on one of those fields would insert the relevant code into the template at the cursor’s position, curly brackets and all, while hovering over one of the fields would display a pop-up with the instructions for that field (helpful to remember whether one is storing only the URL or the full IMG tag in a field). I’m thinking it would look something like this: http://developer.yahoo.com/yui/examples/treeview/tv_tooltip.html

I get you.  I still believe your best bet would be some additional Javascript in the publish page that does this dynamically somehow.  There isn’t another hook that would currently be a good solution for something like that in the publish page.

There a few template page hooks that might work if you wanted to add a link there that gave you what you want.

Have you had a look at the list of available hooks?  It will give you an idea of where extensions can actually make things happen.  If you have a spot in the code that you want to have an additional hook it never hurts to make a feature request as a great many of the current hooks started their lives in that way.

Jamie

EDIT: Whoops, wrong login. Ah well. Now my secret’s out.

Yeah, I just looked at that list today. The edit_template_start & edit_template_end  hooks looked like the ones I’d want to involve, but beyond that, I can’t figure out how to get started. I’d be able to hack the feature directly into the PHP without much problem, but for obvious reasons I don’t want to go that route.

I’d do it myself in a jiffy if I knew how. I read the extensions dev page, but it seems to beat around the bush in a way - it has great information as to how to get the extension installed, updated, disabled, etc, but it’s rather light on information as to where/how the actual work gets done. Also, I noticed there’s a tutorial for creating modules, but none for extensions. Know of any such tutorials on the web? Or would it be too much if I asked for an extension “template” that would add in a placeholder bit of code to the Edit Template page? Once I saw how to get to that point, I think I’d be able to take it from there and write the actual code to fetch all the fields.

Why were you hiding who you were? 

I found the extension dev docs a little confusing at first too.  The thing is, its really going to be a little different depending on the hook.  Thats why the dev docs are a little vague.

Here is the gist of it though.

You create your extension like the docs say with the hook you chose.

In the extension install you have specified a method.  The method is the part of your extension that does all of the work.

Depending on the extension hook you have chosen your method will have different things available to them.  For instance the edit_template_start hook has three variables available to it:

You would call those in your method like this:

The hook will pass off the variables to your method.  Your method does its thing and if appropriate returns a value once it’s done.

It takes a bit of experimentation to work out sometimes.  Doing a search on the hook name in the EE files will give you an idea of where a hook specificly occurs as well.  Sometimes that will help in figuring out your options and the way your method should respond once it’s done.

Jamie

Jamie Poitra - 28 January 2008 08:01 PM

Why were you hiding who you were? 

I wasn’t, really. I’d created this account for my first EE-based client project, and the KKCJ login for a different client. Different accounts, different purchases, “Topic reply notification” emails sent to different addresses… it makes sense. Really.

Although this extension would/will be equally relevant for any of my clients, so whatever. :p

Jamie Poitra - 28 January 2008 08:01 PM

I found the extension dev docs a little confusing at first too.  The thing is, its really going to be a little different depending on the hook.  Thats why the dev docs are a little vague.

Here is the gist of it though.

You create your extension like the docs say with the hook you chose.

In the extension install you have specified a method.  The method is the part of your extension that does all of the work.

Depending on the extension hook you have chosen your method will have different things available to them.  For instance the edit_template_start hook has three variables available to it:

$query
$template_id
$message

You would call those in your method like this:

function my_method($query, $template_id, $message)
{
    
}

The hook will pass off the variables to your method.  Your method does its thing and if appropriate returns a value once it’s done.

It takes a bit of experimentation to work out sometimes.  Doing a search on the hook name in the EE files will give you an idea of where a hook specificly occurs as well.  Sometimes that will help in figuring out your options and the way your method should respond once it’s done.

Jamie

Great, thanks Jamie. I think I’ve got a basic grasp of things now. My only remaining question for the moment is whether the following assumptions are correct:

The bottom-line of what I want to do is to insert a bunch of code right smack in the middle of the template edit form - probably floated off to the side of the big textarea where the editing gets done, which means it would need to come immediately before the textarea tag in the HTML source. I’ve got the impression that the edit_template_start hook, since it doesn’t return any data, would insert anything I gave it far too early in the HTML, correct? So that leaves me with the edit_template_end hook. Since it does return data, would I be correct in assuming that it could give me the entire code of the template editing form to play with, and that I’d need to search through that code for the textarea tag, insert my code immediately before it, and then return the modified template editing form code?

The potential of this extension - if it works - is exciting. I’d always appreciated the fact in Textpattern that you had a dynamic reference to the various tags you could use in a template right there next to the editing field. It made the learning curve much easier. I think this extension could theoretically be expanded to similarly encompass every tag available here, although it would be a butt-load of work to maintain if it can’t pull a tag listing from the database dynamically.