Serendipity Forums

I'm trying to toogle the trackbackgeneration of an entry which was published into the future, but is now released. Thought that should get the job done, but it shows no effect. I also tried to follow the admin/entries.inc.php and to call serendipity_handle_references()...

How can the trackbackgeneration be toggled automatically without saving the entry again manually in the editor?

Hi!

Yes, that does not work.

Trackbacks are only re-triggered if you set an entry to "draft" and then to "publish" again.

Or you delete the entries in the serendipity_references database and store again.

HTH,
Garvin

Does this mean that trackbacks are not generated for future entries?

Hi!

Don Chambers wrote:Does this mean that trackbacks are not generated for future entries?

Yes, it has been this way from day 1 in serendipity.

Regards
Garvin

Learn something new every day I guess!

I want to change that. And it seems to work.
When an entry is saved into the future, no references are created yet (so saving again as draft and publishing is not necessary ). updertEntry was the way to go, just needed to remove loginname and email from the fetched entry.

The last thing needed, which would need modification to the core as far as I can see, would be a way to silence the trackbackgeneration (error and success-messaged are printed to the bottom of the page at the moment). A parameter to updertEntry?

PS: The mechanism is to remember the entry and start the generation after its release as soon as a page gets created.

Hi!

I'd use ob_Start() before calling updertEntry, so you can even store this debug output somewhere, and then discard it.

I saw that you set the rightpublish session var. You should keep track of the original content, and reset it after the update. Else, anyone with a sesssion would be able to publish entries after that.

Also, in the setpuDB routine I would remove the backticks ` so that the code is compatible for SQLite and PostgreSQL. In the end, merging the code into the trackbacks-event plugin would also be a great addition? In that case, its update routine would need some kind of hidden configuration value, and if that does not exist, the plugin would need to create the missing database table.

generateDelayed() should IMHO only inclkude the trackback library, if at least one tracbkack is to be sent, to save some space. otherwise the lib would be included on every page request. Plus, you might want to add a simple random(1, 10) function and only execute the check when that number is 1 - so the overhead of this SQL query would only occur about once every 10 page requests, which should still be sufficient and much less on the performance impact side.

The basic idea of this is very nice, and should work perfectly! MAny thanks for working on this!

REgards,
Garvin

Thanks for your advices

Think I implemented everything, but i'm not totally sure that the place for the database-check is the best choice.

Hi!

Yes, I would place the db_upgradecheck (as well as the $delayed_trackbacks check) inside the generateDelayed() method, as well as inside the backend_save/backend_publish hooks. This way it doesn't get executed everytime...?

Regards,
Garvin

Alright, I stored the upgrade-check in a function and called it in delay() and generateDelayed()
The $delayed_trackbacks moved into the ifs.

Hi!

That's great! Anyone here wants to testdrive the plugin? Don?

I'd like to have it in spartacus of course after a bit of testing )

Thanks for your efforts!

Regards,
garvin

garvinhicking wrote:Anyone here wants to testdrive the plugin? Don?

It will be difficult for me to put this into a live environment that has the combination of future entries AND trackbacks. I can, however, try it in one of my test sites.

Before I do, why is this an event plugin and not a core feature?

Hi!

It needs to execute on a conditional basis, so it actually requires an event hook to execute. Adding a core feature in there would mean a lot of overhead...

Regards,
Garvin

OK - I will give it a try when I take a break from my own s9y headaches with aMember!

>OK - I will give it a try when I take a break from my own s9y headaches with aMember!
That'd be great

>Adding a core feature in there would mean a lot of overhead...
Are you sure about that? We could add the delay() to updertEntry and the check to genpage. Sure, it would mean more code in the core, but (performance-)overhead? Or do you mean the additional database-query of the functionality itself?

PS: Maybe there is even further use for such a cron-like system?