How to set formatting (not == NULL)..

This works for me, with one caveat:

// Get Current Format
$curr_fmt = $row['field_fmt'];

// Get Default Format
$q = $DB->query("SELECT field_fmt AS default_format FROM exp_weblog_fields WHERE field_id = {$row['field_id']};");
$def_fmt = ($q->num_rows > 0)?$q->row['default_format']:'none';

// Decide between Default and Current Formats (i.e. discard NULLs)
$def_fmt = ($curr_fmt==NULL)?$def_fmt:$curr_fmt;

// Get Available Formats
$q = $DB->query("SELECT field_fmt AS format FROM exp_field_formatting WHERE field_id = {$row['field_id']} AND field_fmt != 'none' ORDER BY field_fmt;");
$fmt_opt = array();
foreach($q->result as $res){ $fmt_opt[]=$res['format']; }

$r .= $DSP->input_select_header('field_ft_'.$row['field_id']);
foreach($fmt_opt as $fmt) {
    $name = ucwords(str_replace('_',' ',$fmt));
    if ($name=='Br') $name = htmlspecialchars('
');
    $sel = ($def_fmt == $fmt)? 1: '';
    $r .= $DSP->input_select_option($fmt,$name,$sel);
}
$r .= $DSP->input_select_footer();

The caveat being that $curr_fmt is not actually the current format of the entry you’re editing.

This code, inserted at line 377 of ext.markitup.php will display a dropdown of available formats. It’ll even write the selected format to the DB on submit. However, when the entry edited again, you will see the default format selected in the dropdown, not the currently chosen format according to the DB. This is because the $row[‘field_fmt’] at the beginning of this snippet is actually being pulled from exp_weblog_fields, not exp_weblog_data.

Could you tell me where $field_data on line 376 of exp.markitup.php is coming from? I’m not seeing it.

Sorry, I’m just setting that at the top of the publish_form_field_unique function.

function publish_form_field_unique( $row, $field_data )
{
  global $DB, $DSP, $EXT, $SESS, $LANG;
  // Check if we're not the only one using this hook
  $r = ($EXT->last_call !== FALSE) ? $EXT->last_call : "";
        
  $field_fmt  = $row['field_fmt'];
  $id = $row['field_id'];
...
}

Looks like we’re trying to do the same thing, setting a variable equal to $row[‘field_fmt’];? You’re inseting that at line 377? WOW you have an old version. You should take a look at 1.5.3 (which is my current working version - many, many changes). I’ll PM it to you so you can see what I have.

Thought I’d post this over here too, in case someone else finds it useful. Using the code that Ryan provided above (with a slight modification–$row[‘field_fmt’] instead of $field_fmt):

$r .= $DSP->input_hidden('field_ft_'.$row['field_id'],$row['field_fmt']);

Inserting that into the MD Markitup Extension worked just fine for me. So, if you’re as desperate to have field formatting working in custom field extensions as I am, this may prove to be a temporary solution.

Quick update guys, though it looks like you are coming up with a more concrete solution.

I used this line and for the time being and fixed my MD Markitup, LG Image Manager, LG File Manager.

I found this same problem is affecting Playa in 1.6.5 as well. It seems that when the Playa field_ft is NULL, and I publish, I get a blank white screen. The entry is being saved, and the Playa rel is still being made, just don’t get the usual preview screen after publishing. If I goto the field, change the fieldtype to something where I can change the formatting, change formatting, update all, the go back to playa, then when I publish it works again, no white screen. So when the Playa field_ft is NULL it breaks, when you reset the formatting it fixes it.

Sorry I’ve been out of this one so long. Playing catchup on bug fixes, but trying to get the dev area to be more of a priority.

I can see a couple of ways of going at it: 1. In exp_weblog_fields- what’s going into the field_fmt for the ones that are breaking?

2. Put the hidden field in the form as the above.

3. Cheat- tap into a hook after it’s been submitted, specify them there. Might be a faster fix for when they don’t need to be able to choose. So maybe ‘submit_new_entry_start’. Depending on what’s in exp_weblog_fields- you could query that to get all fields that should be ‘custom_whatever’ and check your post array for matches- set the format then. Or- again check the post array- match key field_fmt_ - for each that’s ”, set a default.

But- I’m not solid on these extensions. If I had a close one to play with- I’m thinking MD Markitup! since you’re going for the dropdown- might get more specific. Ryan, you up for emailing what you’ve got so far? Can send to [email protected] and I’ll take a poke. The key problem right now is the format dropdown and it ‘sticking’ - right? Though- I’m a little confused as to why they can choose a format, cause I thought it was a format. But I suspect I’m a little wrong on that!

Tonight I’m going to experiment with some code Mark D. sent me via PM to see if that works. I would really like to be able to select a format on the Publish/Edit page because sometimes the user needs one field to be formatted differently. I might select Textile as the default formatting (because 99% of the entries in that field can get by with textile), but need that field in one entry to be XHTML, or none - maybe because there is a complex table in it. The way Markitup! is now, the user cannot do that because I could not get the formatting dropdown to work on Publish/Edit screens. I could get it to show…but not work (actually updating with the users new choice). So it currently is all-in on the formatting choice for a field.

Mark’s code may have fixed this. I will be toying with it later tonight.

In answer to your questions:

1. I don’t think anything was getting submitted for field_fmt. Pre-1.6.5, none of us were explicitly setting the formatting. Now we know we have to for custom-field extensions.

2. That seems to work. Now the trick (at least for my extension) is to take it to the next level and allow user to change formatting just like they can on a regular textarea.

Robin, I’ll email you MD Markitup 1.5.3 so you can see what I’ve done (basically added suggestion #2 above), but tonight I’ll be working on 1.5.4 which adds dropdown ability.

1. I don’t think anything was getting submitted for field_fmt. Pre-1.6.5, none of us were explicitly setting the formatting. Now we know we have to for custom-field extensions.

Well, i’ve changed the formatting drop-down to display instead of be hidden, but the value does not seem to get inserted to the database. At least, user’s can fix existing entries by chosing something else than ‘none’, change all entries and then change back to ‘none’.

New entries however seem to get a formatting that’s empty, thus Typography class defaults to ‘xhtml’ when parsing it in the weblog.module file.

My idea (but this does not solve your problem Ryan :() is to maybe use one of the entry hooks to set the formatting explicitely by a SQL query, as you stated. This should work, as for example URL fields (or File manager fields and similar) do not need to have a formatting set.

I hope to be able to test this either tomorrow or on saturday. I’ll report back.

[EDIT] - I notice that while writing this Ryan has posted a reply. I’ll still include what I’ve written, in case it provides any clarity.

Robin -

The format given in exp_weblog_fields is the default set in the Custom Field admin. However, some extensions need to allow the user to modify the format of the custom field. After the 1.6.5 upgrade, extensions that utilized custom fields started having an issue: new entries using those custom fields did not set the default field format (or, indeed, any format) when they were written to ext_weblog_data if they did not set the field_fmt explicitly. Hence, the field_fmt for that custom field was NULL for that entry in the db.

I’m assuming that prior to 1.6.5 the custom entry’s default field_fmt (as chosen in the Custom Field admin) was used if it was not explicitly provided via the new entry form, though I don’t have conclusive proof of this.

Per the discussion above, you’ll notice that we’ve taken the Field Format selection and recreated it for custom fields. In situations where the user has chosen to hide the Field Format selection, we pass the hidden field. To address the NULL entries, if a NULL is detected we reset the field_fmt to the default, as found in exp_weblog_fields.

As Ryan mentioned, I’ve emailed him some code that will query the DB for the field_fmt value for the current entry, as it will differ from the default value if we allow the user to modify it via the Field Format select.

Just to clarify, I’m talking about providing the formatting dropdown for users on the front-end of the site. But peschehimself, I see your issue and raise you 3 hours of hackery.

Hm- Ryan, are you talking about the SAEF? Or the backend publish/edit page? I’ll likely know more as soon as I install and play around a bit. Thanks for getting me a good example script.

And I’m pretty sure the change is to the database- the field_ft_x field in exp_weblog_data was changed to tinytext- which won’t take a default, so defaults to null. I believe the field itself used to default to xhtml. So basically, the code wasn’t putting in a default, but since the db field had one, that’s what you ended up with. Changing the db field type resulted in the NULL going in instead. Make sense?

Talking about a regular ol’ Publish/Edit page on the backend. I started a thread over here last month, begging: Has anyone written a custom field extension that uses the formatting dropdown

There is a screenshot there showing my custom field with the formatting dropdown beneath it.

I’m really hoping that incorporating Mark’s code will allow a Markitup user to change formatting on the Publish/Edit screens!

Also, if someone could change the title of this thread to read something like “How to set custom field formatting (not == NULL) in extensions” or similar so it’s easier to find again through a search. Maybe I’ll just throw some tags in here: custom field formatting, custom field NULL, custom field extension.

You doubt? :D

Drop what I sent at line 750, and I’m almost certain it will work like a charm. Mine is, anyway, on 1.5.3.

I just updated Markitup (with a few tweaks) and it’s working great. The only place is doesn’t work is when a user clicks “Quick Save”, and I suspect that is because the entry_id is not in the URL on a Quick Save. (I know QS has been the cause of many headaches for developer in the past). What this does then is, even if I’ve changed to a different format since, because the entry_id is not in the URL, the fields go back to their defaults.

If there is a different way to get the entry id (other than using $_GET[‘entry_id’], as it is currently doing), or to not make any changes when doing a “quick save”, we’re golden.

(And I think we hijacked this thread)

EDIT/ADD: I just added this: $thisentry = $IN->GBL(‘entry_id’);. Just noticed too that the first time you click “Quick Save” things work, but the entry id will no longer be in the URL at that point…so changing a format again and clicking Quick Save will fail the second time.

(And I think we hijacked this thread)

In that case, I demand you take this thread to cuba.