Works for me on 3.4.8, but I did have to amend the code slightly. I followed the instructions as included in what you download, and then after installing the two 'Media Tag Replacements', I clicked on the 'edit media tag' link to the rigtht of each of them, and amended the text in the 'Media Replacement HTML' box., to add "http:" to the script source URL.
<blockquote class="twitter-tweet"><a href="https://twitter.com/$1/status/$2"></a></blockquote><script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>[/code]
[code]<blockquote class="twitter-tweet"><a href="https://twitter.com/$1/status/$2"></a></blockquote><script async src="http://platform.twitter.com/widgets.js" charset="utf-8"></script>[/code]and then the same process for the 'Tweet Embed Statuses' It's also worth noting that you won't see anything if you make your embedded tweet post via the 'quick post' box which doesn't reload the page. You'll need the page to be fully-freshly loaded to see the embedded tweet.
The default words of someone too stupid to engage their brain.
as currently exists, yes. It's the only option.
My first post was to say I wished there was another, better option. Because there *ARE* better options, if they were built into the IPB code.
It's not irrational to want the simplist solution which creates the least server load.
It is irrational to be unable to recognise that things can be done in different, and sometimes better, ways.
No, I just understand one-sided stupid views are not the only views. Given that this thread is full of one-sided stupid views I thought I'd offer up an alternative, as a way of perhaps pointing out others stupidity.
Not everyone is so stupid to think that any action a nation state or supranational organisation might make is automatically bad, or even purposeless. :)
no, just someone with 30 years of computing experience who wishes to mqake optimum use of his already busy servers.
the stupid are those who cannot think because they'rew blinded by their prejudices. ;)
it is not a viable solution within my working parameters - which is what I'm trying to get thru to people here. :rolleyes:
There would be no 'parent file' - which would be a IPB hook. That has an extra overhead of it's own, before getting to what the hook might do (either internally, or externally by loading in a php-include).
I don't want to hack it - it's because I don't that I'm posting here. :)
because it's *only* the include, whereas via a hook it's the hook *and* the include.
The difference might be small, but there is a difference. And that small difference can be the difference between my forums continuing to work in a usable manner, and not working at all.
(yes, I could spunk another £5k on bigger/better/more servers, but that requires me to have that £5k, and the inclination to spend it on those servers - which, for the less than 48 hours each year that my servers max out, isn't worth it).
It's no less precise. How could it be? What would get run with any *real* purpose is the include and nothing else.
But it becomes a problem when I'd need to do the same file hacks after each upgrade (been there, done that), which is why an easy way to include a single php-include across all skins would be the ideal solution.
I can't quantify it, no. I'm not so anal to do a full analysis.
But it *is* extra load within the IPB 'engine', which itself knows it has a load issue - which is precisely why there's a need for it to have a 'performance mode' (which is something I have to use at a points).
All I need to do is read a cookie and display a bit of text at the top of the page dependent on that cookie's setting. Nothing of this needs to put anything but the tiniest load onto my server - while doing it thru IPB will put significantly more onto my server.
The difference between methods might be small against what the server is able to handle, but that difference probably amounts to 100 extra users at nearly 10,000 simultaneous users.
I have to hack my skins each time IPB does an update anyway, so where's the difference?
I don't wish to add to the load thru the IPB 'engine' when a minimal solution is far far better for an extremely busy site. For some of us, those tiny differences in load get to make a very big difference to site usability at peak loads.