Wanting a DRY place to keep a maintainable file download description

alanfluff · 2009-09-27 15:21:03

Hi Cleverer than me TXPers,

I am using for the first time, the file_download_description tag.

I see that although TXP allows maintenance of a files description, the updated description is not reflected by the file_download_description tag — it shows a snap-shot of the description entered at file-upload time.

I am sure there are cases where this permanency is called for, cool.

However, I want to use the ‘Files’ section of the Admin to upload files, and to describe the files there in that one spot, and then be able to use those descriptions at will throughout the site. And when I realise a description is wrong, to be able to edit it and the new copy to appear wherever I have used the file_download_description tag.

I can’t find a way for std TXP to do this. Or a plugin.

Has anyone else had this problem and solved it? Or am I being naive and missing the importance of the way TXP ‘snap-shots’ the description and does not output updated versions?

Any comments MUCH appreciated, not expected just appreciated :)

Cheers, -Alan

jsoo · 2009-09-27 15:29:09

alanfluff wrote:

I see that although TXP allows maintenance of a files description, the updated description is not reflected by the file_download_description tag — it shows a snap-shot of the description entered at file-upload time.

Nope, that’s not how it works. Are you sure you are saving the edited description? Do you have some kind of caching that could explain this?

alanfluff · 2009-09-27 16:52:11

@jsoo Oh? Thanks for putting me right, it did seem a bit odd.

I tried again and still, editing the description in the Files tab did not reflect in the Article.

But, for some reason I thought “I wonder if I need to re-save the article(s) that have this file referenced?”. So I did, and that worked.

This seems a solid sequence now, I can edit the Files Description as much as I like, re-fresh the viewed Article as much as I like, and no change, but if I open to Edit and then just save the Article, then it seems to re-snap-shop the Description and it is updated with the latest version.

Does this seem right?

If so then I guess I just find all Articles where a changed File is referenced and re-save them.

THANKs for the comment.

Cheers, -Alan

jsoo · 2009-09-27 17:45:04

Sounds like a caching issue, where your persistent page refreshing is still not generating a new page for some reason.

alanfluff · 2009-09-27 17:54:07

@jsoo Ok, thanks. Weird eh? I’ll keep looking to see if I find out more about this and report back on this thread as/when I do in case it’s helpful to anyone.

Thanks again, cheers, -Alan

jakob · 2009-09-27 19:31:18

From what you write, your file download tag is written manually in the article. How have your written your file download in the article?

Textpattern processes the textile of the article body and saves it as html in the background when you save an article. This is what is shown when the page is viewed. I guess the reason for this is that it can be displayed without having to processed every time the page is viewed saving time and server sources. That might explain why the changes are only visible once you re-save the article.

Another way of getting around this would be to associate a file ID with the article (in the same way as you do with article images) and display it through your page template rather than hard-coded in the article body. upm_file will allow you to do this. This depends, of course, on how you have set up your site and where your download has to appear.

jsoo · 2009-09-27 19:34:50

That isn’t it — look at the ~~html_body~~ Body_html field for an article containing Txp tags. Textile conversion happens when you save the article (to speed page load as you point out), but Txp tags aren’t processed until the page is served.

Last edited by jsoo (2009-09-27 19:37:02)

jakob · 2009-09-28 06:55:33

jeff, thanks for putting me right! You’re right I hadn’t done the fine-grain analysis of checking the Body_html for an article with txp tags.

The workaround with upm_file should still be valid, though.

alanfluff · 2009-09-28 12:41:49

@jakob

From what you write, your file download tag is written manually in the article. How have your written your file download in the article?

Yes, I have written this in the Article via the regular Admin content editing route:

<txp:file_download id="4" />

Thanks for pointing to upm_file.

@jsoo Thanks also for your comments. After a quick Google I still don’t know what the Body_html field is but no worries, I’ll research more.

Thanks for the help.

My aim was simply to be able to allow a user to write copy such as:

h2. The support files you want are

# <txp:file_download id="4" />
# <txp:file_download id="5" />

You may also like to look at <txp:file_download id="6" /> as it's helpful also.

In other words, ideally, I would like to tell the writers that they can drop file_download tags in as/when they like and descriptions will all automagically come with and will be always up to date with the latest Description in the files entry in the File tab.

Sounds like upm_file can do what I want, but just not allow me to have file_download tags scattered wherever I like in the copy? I’d instead need a dedicated place in the Article where my list of file(s) appears? If I read the help for the plugin correctly?

NOT complaining here at all – just most interested in this apparent difference between the ease with which a writer can put in links to images as/when they want and the latest associated meta is automatically used (title attribute etc), and the way file_download meta works.

Thanks again for comments.

Cheers, -Alan

jakob · 2009-09-28 13:12:53

still don’t know what the Body_html field is but no worries

This is an additional field in the txp database which one never normally sees – as such you don’t need to worry about it and you can’t access it directly. Textpattern saves what you write in the Body box to the Body field of the database. At the same time it runs it through its textile processor to produce html output which it saves in the Body_html field of the database for future use so that it doesn’t have to do this processor-intensive job every time the article is viewed, only every time it is saved.

Sounds like upm_file can do what I want, but just not allow me to have file_download tags scattered wherever I like in the copy?

Yes that’s right – that is the disadvantage. That was what I meant with This depends, of course, on how you have set up your site and where your download has to appear. You may be able to get around this with some appropriate wording.

jsoo · 2009-09-28 13:55:39

alanfluff wrote:

NOT complaining here at all – just most interested in this apparent difference between the ease with which a writer can put in links to images as/when they want and the latest associated meta is automatically used (title attribute etc), and the way file_download meta works.

Again, the behavior you are getting is not expected, nor is it likely a Txp issue per se. Although you could try disabling caching and see what that does. How to do that, and a bit more info about caching issues, here. It is quite possibly a browser issue, or a server issue.

alanfluff · 2009-09-28 14:42:19

@jakob

Thanks. Got it.

@jsoo

Oo. Good to know it’s something to do with me and that File meta will work as brilliantly as Image meta once I sort out whatever weird caching thing I seem to have going on.

When I fix it I’ll report here for completeness/in case helps others.

Thanks a lot chaps for all. Cheers, -Alan

Textpattern CMS

Textpattern CMS support forum

#1 2009-09-27 15:21:03

Wanting a DRY place to keep a maintainable file download description

#2 2009-09-27 15:29:09

Re: Wanting a DRY place to keep a maintainable file download description

#3 2009-09-27 16:52:11

Re: Wanting a DRY place to keep a maintainable file download description

#4 2009-09-27 17:45:04

Re: Wanting a DRY place to keep a maintainable file download description

#5 2009-09-27 17:54:07

Re: Wanting a DRY place to keep a maintainable file download description

#6 2009-09-27 19:31:18

Re: Wanting a DRY place to keep a maintainable file download description

#7 2009-09-27 19:34:50

Re: Wanting a DRY place to keep a maintainable file download description

#8 2009-09-28 06:55:33

Re: Wanting a DRY place to keep a maintainable file download description

#9 2009-09-28 12:41:49

Re: Wanting a DRY place to keep a maintainable file download description

#10 2009-09-28 13:12:53

Re: Wanting a DRY place to keep a maintainable file download description

#11 2009-09-28 13:55:39

Re: Wanting a DRY place to keep a maintainable file download description

#12 2009-09-28 14:42:19

Re: Wanting a DRY place to keep a maintainable file download description

Board footer