Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: size limitation in forms?
We could reduce the memory consumption (at the price of a slight runtime increase), storing only top-level tags of each parsed $thing
. But optimizing your txp code will never hurt.
Offline
Re: size limitation in forms?
Nah, the parser’s great. It’s the tag code in this case that needs refactoring
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: size limitation in forms?
Bloke wrote #325373:
Nah, the parser’s great. It’s the tag code in this case that needs refactoring
+1. I am studying it:)
The issue is that there appears to be very little commonalities amongst hosts for their embed iframes. Furthermore, GDPR demands that the privacy statement from each host is linked to, and again all these addresses are different.
I find youtube’s approach the best regarding their urls for videos, images and the embed codes. it makes perfect sense and it may have a little something to do with its popularity.
In contrast, vimeo needs an API key in order to parse images to external sites and the urls of those, have nothing to do with the video urls, which is the reason I omitted them.
It needs thinking!
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: size limitation in forms?
colak wrote #325374:
there appears to be very little commonalities amongst hosts for their embed iframes.
Maybe. But there aren’t an infinite number of ways of rendering a media clip. You should be able to group them. Type A use the same URL key for cover images. Type B need an API key, and so on.
If you could classify them that way, you’d know which ones take which options. Then cater to the various types and make sure you pass in the relevant parameters. If someone supplies the wrong params or misses one, your default cases will fill in the blanks or allow the shortcode to fail gracefully.
That way, you don’t need if type=‘vimeo’ then do this. And another block if type=‘dailymotion’ then do this. If you know both those services use broadly the same flavour of iframe, you can set up your variables from all the yields passed in and then do:
if type=“vimeo, dailymotion, …” match=“any” then …
GDPR demands that the privacy statement from each host is linked to, and again all these addresses are different.
This is what is complicating things in the current setup. Maybe you could collate all the URLs at the start in a huge privacy table:
<txp:variable name="privacy_youtube">https://youtube.com/privacy</txp:variable>
<txp:variable name="privacy_vimeo">https://vimeo.com/privacy-policy</txp:variable>
<txp:variable name="privacy_bandcamp">https://bandcamp.com/policies/privacy</txp:variable>
...
Then you can just grab the relevant variable when you do know the type:
<a href="<txp:variable name='privacy_<txp:yield name="type" />'">Privacy policy</a>
vimeo needs an API key in order to parse images to external sites and the urls of those, have nothing to do with the video urls
The example URLs they give out are different keys indeed if you’re logged in, but if you actually try passing in the same key as the video URL itself, it actually does work (or at least it seemed to in my tests).
I might be wrong, but they’d be daft to make it more difficult than necessary to get the cover image for a video when users want to link to the service. If they do make it more difficult, that might partly explain why they’re not the dominant video provider in the marketplace!
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: size limitation in forms?
I might be thinking about it in the wrong way but there is nothing wrong, memory wise, with the privacy policies as they are just html.
One way I am thinking is to split the form into 4 forms which could be based on popularity.
The media
template could host the variables and a growing number of if_yields
. Something like
<txp:if_yield name="from" value="yt"><txp:output_form form="media_popular_a" /></txp:if_yield>
<txp:if_yield name="from" value="v"><txp:output_form form="media_popular_a" /></txp:if_yield>
<txp:if_yield name="from" value="pt"><txp:output_form form="media_popular_c" /></txp:if_yield>
...
A second, lazy way, would be to have the media
form as described above but create a new form for each host.
Maybe if there is a way to evaluate if a form exists I’ll just need a few lines of code.
<txp:variable name="check_form"><txp:output_form form='media_<txp:yield name="from" />' /></txp:variable>
<txp:evaluate test='<txp:variable name="check_form" />'>
<txp:variable name="check_form" />
<txp:else />
<txp:if_logged_in>
<p class="error">Error: There is no <b><txp:yield name="from" /></b> host using the <b>from</b> attribute.</p>
</txp:if_logged_in>
</txp:evaluate>
I know that this untested method might over-populate the forms side, but it may be the most efficient memory-wise. I nevertheless do not know what happens, memory-wise, to articles/pages that may host a number of embeds from various hosts and if the evaluate tag will work.
On the positive side, the code will be totally modularised and those who may be interested in this shortcode, will only be needing to download the media
form, and the forms for the hosts they use.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: size limitation in forms?
Bloke wrote #325375:
The example URLs they give out are different keys indeed if you’re logged in, but if you actually try passing in the same key as the video URL itself, it actually does work (or at least it seemed to in my tests).
I might be wrong, but they’d be daft to make it more difficult than necessary to get the cover image for a video when users want to link to the service. If they do make it more difficult, that might partly explain why they’re not the dominant video provider in the marketplace!
My tests return different imgs for example video id 7430730 returns 782791131.jpg and 7430730.jpg belongs to an unknown video.
I think that there are good things with vimeo such as no advertising as they rely on the paying users for their revenue. Their codecs are excellent and they produce better quality streams. On the down side they have limitations on how much one can upload for free. For the paying users, they delete their videos once they stop their subscriptions. URLs are of course another issue, as well as their unnecessary use of third party analytics in their site.
I am considering to recommend to the NeMe committee to re-upload most of our videos to as many hosts as possible, starting from the Internet Archive and YouTube, in order to extend their life-span, and audience, beyond our platform of choice.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: size limitation in forms?
colak wrote #325377:
My tests return different imgs for example video id 7430730 returns 782791131.jpg and 7430730.jpg belongs to an unknown video.
Okay, I might have got mixed up then, sorry. It worked for soundcloud. Thought it might be the same for Vimeo.
The trouble with this approach is that you can get all the info you want if you supply the URL to the video, as you get back all the info you need. But since you want to get the cover image directly without trying to use the URL first (because accessing the video URL violates GDPR) then you will likely need to jump through a lot of hoops to get it.
The alternative is to provide a fallback with a simple ‘play triangle’ and no cover image in cases where it is difficult to retrieve. Not ideal.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: size limitation in forms?
Images are indeed an issue I am struggling with but I have to admit that tags is another. I actually hoped that my second example above would yield some results but in spite of the evaluate tag returning true
, the error appears. Here’s the relevant tag trace:
70.67 | 4.73 | <txp:variable name="check_form"> |
70.68 | [true] |
|
… | … | tags in the output form |
75.40 | </txp:variable> |
|
75.40 | 0.07 | <txp:evaluate test='<txp:variable name="check_form" />'> |
75.41 | 0.02 | [attribute 'test'] |
75.41 | [true] |
|
75.42 | 0.01 | <txp:variable name="check_form" /> |
75.43 | [/attribute] |
|
75.44 | [true] |
|
75.45 | 0.02 | <txp:if_logged_in> |
75.46 | [true] |
|
75.46 | 0.01 | <txp:yield name="from" /> |
75.47 | </txp:if_logged_in> |
|
75.47 | </txp:evaluate> |
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: size limitation in forms?
Hi Yiannis,
here is <txp:evaluate />
doc, it works like this:
<txp:evaluate>
<txp:output_form form='media_<txp:yield name="from" />' />
<txp:else />
<txp:if_logged_in>
<p class="error">Error: There is no <b><txp:yield name="from" /></b> host using the <b>from</b> attribute.</p>
</txp:if_logged_in>
</txp:evaluate>
Offline
Re: size limitation in forms?
here is
<txp:evaluate />
doc, it works like this:
<txp:evaluate>...
Thanks Oleg, It is where I picked mine from, wrongly adapting <txp:evaluate test="linklist">
to <txp:evaluate test='<txp:variable name="check_form" />'>
Your suggestion does indeed work except when the form does not exist, at which time, a txp error is understandably loaded when on debug. So two questions
- Do you think that this method will be easier on the parser?
- Is there a way to check for the output form quietly so as to supress the back end error and just show the front end one for logged in users?
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: size limitation in forms?
colak wrote #325381:
- Do you think that this method will be easier on the parser?
Certainly, since it will have to parse only the relevant code (thought at a price of one extra db query).
- Is there a way to check for the output form quietly so as to supress the back end error and just show the front end one for logged in users?
AFAIK, only by somehow putting the site in ‘live’ mode.
Offline
Re: size limitation in forms?
etc wrote #325382:
Certainly, since it will have to parse only the relevant code (thought at a price of one extra db query).
AFAIK, only by somehow putting the site in ‘live’ mode.
Thanks so much. I think that most will be able to live with both!
Expect a new version for this shortcode soon:)
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline