Callback for saving own new fields

demoncleaner · Yesterday 21:05:33

I have more or less successfull managed to generate a Plugin that gives me complete set of new fields for the edit article page.
the idea is to have multiple checkboxes and fields customized for a real estate Website to maintain properties. glz_custom fields is not enough in that case because I really wanted to create my own kind of backend template for setting up the fields etc.

That all works great. The only little issue is, that when I save it it does not show the green notice “article saved” (but actualy does save) and when I save twice I always get the error message that meanwhile the admin changed the article and nothing was saved.

I don´t want to post my whole plugin script now but I narrowed it down to the callbacks and to my save function.

I use those callbacks:

register_callback('acf_custom_fields', 'article_ui','excerpt');
register_callback('acf_custom_fields_save', 'article_saved');
register_callback('acf_custom_fields_save', 'article_posted');

It seems that only using both _save callbacks successfully change the data of my new fields. My save function contains that:

safe_update(
            'textpattern',
            "$name = '" . doSlash($value) . "'",
            "ID = " . intval($articleid)
        );

Has anybody ever created custom fields (not the txp custom fields) through a plugin and managed to save them correctly?
The way things are saved in txp seem very confusing.
Would be great if someone had an idea what causes the error messag on every second save-attempt.
Could that be due to the lastmod entry not beeing in sync?

jakob · Yesterday 23:53:57

The devs are more qualified to answer this than me, so it’s wiser to wait to hear from the experts, but …

a) Attaching your callback function to both article_posted and article_saved ensures it is called on first posting of a new article and on editing an existing article.

b) As far as I remember (sketchy here, sorry), you can either have your plugin insert new fields where you want them and then update them when you save asychronously (see how bot_wtc does it by hooking into the txpAsyncForm.success callback; glz_cf does something similar) or you can extend the existing array of $partials that exist on the article pane and make a function for each. Then textpattern takes care of the refreshing (right devs?).

demoncleaner · Today 08:06:53

Thanks jacob, it brought me on the right track.
However my problems originated somewhere where I did not expected them. It seems to be ok to have those two callbacks.

I was also looking into glz_cf to check how they do it. But it is a little different here. They actually do not “create” any new fields that would need to be “declared” in a way.

But my problem was that I tried to write into “Excerpt” twice. Once in the original process and once again by adding a new field that should simply overwrite the original field. But that does not work like that.
I overcome this problem by having second safe_update.

 $excerpt_value = trim(ps('cp_reference'));
          safe_update(
              'textpattern',
              "Excerpt = '" . doSlash($excerpt_value) . "'",
              "ID = " . intval($articleid)
          );

And another problem was, that I had so many fields that I over saw that one field was actually missing in the database. Both mistakes created the same problem that I originaly posted. This made it hard to debug.

jakob · Today 08:45:37

demoncleaner wrote #341502:

I was also looking into glz_cf to check how they do it. But it is a little different here. They actually do not “create” any new fields that would need to be “declared” in a way.

Yes, glz_cf extends the existing custom_field mechanism, but it does create new columns for each field.

my problem was that I tried to write into “Excerpt” twice. Once in the original process and once again by adding a new field that should simply overwrite the original field. But that does not work like that.
I overcome this problem by having second safe_update.

I have a mini self-made plugin that adds a few extra custom textile helpers and it first retrieves the body_html field from the currently posted/saved item, then does its changes and resaves the field.

if (txpinterface === 'admin') {
    register_callback('jcr_textile_helpers', 'article_posted');
    register_callback('jcr_textile_helpers', 'article_saved');
}

function jcr_textile_helpers($event, $step, $rs)
 {
    // get 'Body_html' field from currently saved/posted article or exit if unsuccessful
    if (!($row = safe_row('Body_html', 'textpattern', 'ID='.$rs['ID']))) return;
    // turn retrieved field(s) into variables named after the field
    extract($row);

    // put your replacement stuff for $Body_html here …

    // re-save escaped 'Body_html'
    $Body_html_postprocessed = doSlash($Body_html_postprocessed);
    safe_update('textpattern', "Body_html = '$Body_html_postprocessed'", 'ID = '.$rs['ID']);
}

but I think you can also hook in earlier in the process and modify a field before it gets posted. See the callback reference. Bloke or Oleg can probably explain that better.

This made it hard to debug.

You probably know these already, but you can stick a ,1 to the end of safe_functions to get debug output of the queries it produces. And dmp($your_variable_or_array); shows you output at certain points.

Two other tricks for actions that don’t happen on a page, and so don’t get reported on the page:

Open up the webinspector when making your submission and check for another existence of index.php in the sources/network panel. It’s only spawned for the submission but can contain an error message. Also useful for debugging com_connect submissions.
If you add the following to your config.php:

define('txpdmpfile', 'debug.txt');

it diverts error output (including your dmp) to /path/to/your/tmpdir/debug.txt. Note: you don’t get errors in your pane anymore, though.

I had so many fields that I over saw that one field was actually missing in the database.

Are you making your own front-end tags to output these, then? Or using etc_query / smd_query to output these new fields.

etc · Today 09:22:36

demoncleaner wrote #341493:

The only little issue is, that when I save it it does not show the green notice “article saved” (but actualy does save) …

It is often caused by warnings in debug/test mode, you might want to inspect the server response. Async requests are expecting a valid js response, but warnings make it invalid.

jakob wrote #341506:

I think you can also hook in earlier in the process and modify a field before it gets posted.

Yes, txp 4.9 has ('article_submit', 'post|save', '1|0') callbacks that one can use to alter article fields before textile/save. Dunno if it helps here, but see around l.190 of txp_article.php.

jakob · Today 09:50:14

etc wrote #341516:

It is often caused by warnings in debug/test mode, you might want to inspect the server response. Async requests are expecting a valid js response, but warnings make it invalid.

Yes, txp 4.9 has ('article_submit', 'post|save', '1|0') callbacks that one can use to alter article fields before textile/save. Dunno if it helps here, but see around l.190 of txp_article.php.

Interesting (link to code). So that means in the above example I could probably save both queries by using article_submit and the 0 option – because I want to add some stuff to the already textiled output – and do my modifications to $incoming['Body_html'] and then return $incoming at the end of the function. Textpattern then goes ahead and does the rest, including saving to the DB.

And demoncleaner could potentially also use article_submit but with the 1 option to switch out $incoming['Excerpt'] with his own field’s content before letting Textpattern textile the content [if he’s using txp 4.9].

Bloke · Today 10:17:07

^ Correct. The pre/post flag is one of the things that a lot of the callbacks don’t sadly employ in a uniform manner.

Come the revolution, all callbacks will be (at least) in pairs. One pre-Txp involvement and one after it’s done its bit. Some panels have additional ‘during’ style callbacks so you can alter the actual content of the page (e.g. extend tables or add custom steps for your own handlers).

The notion of ‘pre’ and ‘post’ has been subtly enhanced in 4.9.0 so it’s not just limited to pre=1 and post=0. You can actually pass any string to the pre/post value when you register a callback, allowing plugins and themes to intercept at any stage. This sort of ‘sub-step’ allows us to wire up better callbacks, e.g. :

Current event.step.pre	Potential future event.step.pre
article_saved	article.save
article_posted	article.save.new
image_deleted.image	image.delete.1 (pre) / image.delete.0 (success) / image.delete.fail

…

I have a branch (somewhere) knocking around where I started work on building a HUGE table of current -> future callback mappings. I didn’t get past about 4 panels before I got sidetracked.

demoncleaner · Today 10:50:03

Thank you so much guys. So many valuable information. A bit like xmas…
For the record: I am on the latest (I guess) 4.9.0 and yes I have my own frontend tags.
And as always I am pretty stoked with what can be achieved with textpattern as a base.

Last edited by demoncleaner (Today 10:50:29)

Textpattern CMS

Textpattern CMS support forum

#1 Yesterday 21:05:33