Hi! Looking for a bit of guidance to resolve some trouble I’m having with setting up a Twitter feed using the “Twit” plugin – if there’s another method for displaying a Twitter feed that is perhaps easier, I’m open to trying that as well. Also, this is the first plugin I’ve used with Kirby, so I might have missed something basic.
The version of the plugin listed here on Kirby’s site is out of date, but I’m using the current version, from this Github page. I’ve followed the developer’s instructions by creating a plugins folder inside site and placing the contents of the repo inside. I’ve also registered for access to the Twitter API and copied the necessary key / token / etc. into my config.php file.
After completing the above, I tried to test the plugin by pasting the following snippet into my home.php file. However, my site now goes into debug and throws the error “Undefined variable $excludereplies”.
I’m not technical enough to know what steps I might take to debug this, so any help or advice would be very much appreciated!
Sorry, my earlier reply overlooked the important detail that that code in the Whoops screen is not yours, but from the plugin’s snippet. Early morning…
I don’t have a way to test this right now, but this might be a bug in the plugin or its docs: the snippet expects lowercase variables whereas the readme advises to use camelCase?
If the error persists following @texnixe’s advice, try using excludereplies instead of excludeReplies in that snippet call (same appears to apply to screenname).
After completing the above, I tried to test the plugin by pasting the following snippet into my home.php file.
The snippet you shared was the one I was referring to (but forgot to include in my post, my bad). That said, it looks like @sebastiangreger’s suggestion was onto something. I edited the snippet to convert both variable names you mentioned to lowercase, and it appears to have resolved two of the errors I was encountering. However, I subsequently ran into another error, which seems to reside somewhere within the plugin’s files: Undefined array key "full_text"
Glad to hear you could solve it; docs and code are indeed not matching up. If you find a moment, please consider alerting the developers with a Github issue.
Looks like the plugin’s internal tweet.php snippet expects a field full_text for every tweet, which in at least one of your tweets’ payload seems to be missing (or something else, really hard to evaluate without deeper knowledge of the inner workings). Maybe @jimbobrjames has an idea?
If you want to try troubleshooting this yourself, you could try copying site/plugins/kirby3-twitter/snippets/tweet.php to site/snippets/tweet.php (or edit straight in the plugin folder for a quick test run) and replace the offending line 5 (echo <p>…) with dump($tweet). If everything else works as it should, that would display the raw data of your retrieved tweets and could also help the developers to pinpoint the source of the issue (for example if the API indeed returns some tweets without that expected full_text field).
If you want to try troubleshooting this yourself, you could try copying site/plugins/kirby3-twitter/snippets/tweet.php to site/snippets/tweet.php (or edit straight in the plugin folder for a quick test run) and replace the offending line 5 ( echo <p>… ) with dump($tweet) . If everything else works as it should, that would display the raw data of your retrieved tweets and could also help the developers to pinpoint the source of the issue (for example if the API indeed returns some tweets without that expected full_text field).
I happened to come across and read a .cache file left by the plugin, and it seems the issue now is quite separate.
{“created”:1638948828,“minutes”:30,“value”:{“errors”:[{“message”:“You currently have Essential access which includes access to Twitter API v2 endpoints only. If you need access to this endpoint, you\u2019ll need to apply for Elevated access via the Developer Portal. You can learn more here: https://developer.twitter.com/en/docs/twitter-api/getting-started/about-twitter-api#v2-access-leve”,“code”:453}]}}
So it looks like the API call is working, but Twitter has made changes to their API recently which blocks most (newer) users from accessing an endpoint that was previously accessible to anyone registered on their dev platform. A note on the page from the Twitter Dev Platform docs that they link to says
Please note:
If you were approved for a developer account before November 15th, 2021, will were automatically converted to Elevated access. This means that your existing Apps can continue to be used to make requests to standard v1.1, premium v1.1, and enterprise endpoints, and that all of your user Access Tokens are still valid.
I’ve already looked into applying for ‘Elevated access’ but it doesn’t seem like a viable path for what I’m trying to use the API for (the application asks for details I can’t provide). I’m somewhat at a loss when it comes to navigating these API docs myself, but I’m wondering if it’s likely that there is still a way to access the tweets using the API v2?
It is late for me, so I have to leave it there until tomorrow, but that’s what I’ll look into next. Thanks again!
Yes, it does look as tho Twitter has changed something recently by what is in the cache file. I will look into this later today, but it likely just needs an upgeade to the underlying oAuth library that the plugin uses to make the connection.
@JoshApos This has been fixed. I just tested the plugin to be working fine on Kirby 3.6.1. The composer dependencies needed upgrading. Please reinstall the plugin manually or do a composer upgrade.
I fixed the issue with the camel casing too, so you will need to revert that snippet call back to being camel cased.
@jimbobrjames Wanted to followup on the message you sent over Discord:
you may still hit issues which i think are related to PHP 8, im hoping to solve these later today
Would the PHP 8 issue cause the same error re: API access level? I ask because I’ve updated the plugin and I’m getting the same message in the .cache file about not having the proper API access level.
From what I just learned about TwitterOAuth and the recent introduction of those Twitter access levels: it seems that TwitterOAuth still defaults to v1 of the API whereas developer users with the “Essential” access level are required to use v2.
@JoshApos: maybe you could try to edit the init() method in site/plugins/kirby3-twitter/src/classes/Twitter.php (line 38 onwards) by adding a line to set the API version as follows:
public function init()
{
self::$connection = new TwitterOAuth(
option('twit.consumerkey'),
option('twit.consumersecret'),
option('twit.accesstoken'),
option('twit.accesstokensecret')
);
// add the following line:
self::$connection->setApiVersion('2');
}
This should switch the kirby3-twitter plugin over to using APIv2 instead of the default v1 which developers with dev accounts predating Nov 15 still have access to as they were granted “Elevated” access level automatically.
…if my hypothesis proves valid, this would at least resolve the error in the cache file; not sure whether the plugin is able to deal with a v2 response payload out of the box, but that would be a separate thing to investigate then.
I definitely think your hypothesis is on the right track. It’s possible that @jimbobrjames was testing with an older Twitter Dev account that was grandfathered into the “Elevated” access level, and thus the plugin functioned mostly as expected once the camelcase errors were fixed.
That said, self::$connection->setApiVersion('2'); is throwing a new error:
Call to undefined method Abraham\TwitterOAuth\TwitterOAuth::setApiVersion()
Maybe best to take this to Github: Issues · HashandSalt/kirby3-twitter · GitHub – I opened one issue re the “v2 hypothesis” and another one to tackle that newest error (the bundled TwitterOAuth library does not appear to be the most recent version).
(Please let me know if there is a better place to post this, whether that’s opening an issue on Github or a new thread here on the forum)
To my surprise, Twitter accepted my application for Elevated access to the API instantly. I’ve confirmed as well that the .cache file contains the expected tweets and accurate associated metadata. So it looks like I’ve successfully sidestepped the issues arising from the new version of the API.
Now that that’s solved however, Kirby is throwing a new error:
TypeError HashAndSalt\Twitter\Twitter::linkify(): Argument #1 ($value) must be of type string, null given, called in /Users/[myComputer]/[myDevDirectory]/site/plugins/kirby3-twitter/src/classes/Twitter.php on line 142
