Yes, but for the moment all I have is the perch admin control panel via the website, and FTP access to the web files exclusively. I've put in the request to have the database tables dropped recently, and I'm waiting to hear back about it.

Okay, the database admin got back to me and said that he dropped the tables associated with perch_twitter. I logged in and verified that the entire timeline of tweets had been wiped out.

I also got a chance to look at their apps.twitter.com page, and verified that the callback URL was set to the homepage of their site that should be using perch_twitter. So that pretty much negates my guesswork that something might have been in error on that front. They are giving the application read and write permissions and the records I took of their previous configuration suggests that they were using the correct consumer key and consumer secret.

I will try to re-enter the details and re-acquire the tweets once again. If anything unusual comes up, I will write an addendum detailing any error messages I see.

Okay, I tried the full process of authorizing the app, and it coughed out the same sequence of errors that it had before, albeit with several additions that I had not been aware of up until this point.

Fourty lines of this:

Notice: Trying to get property of non-object in C:\inetpub\dev\admin\addons\apps\perch_twitter\PerchTwitter.class.php on line 163

Which was subsequently followed by several lines of the following which I had not seen before:

Warning: Cannot modify header information - headers already sent by (output started at C:\inetpub\dev\admin\addons\apps\perch_twitter\PerchTwitter.class.php:163) in C:\inetpub\dev\admin\core\lib\PerchUtil.class.php on line 1405

Warning: Cannot modify header information - headers already sent by (output started at C:\inetpub\dev\admin\addons\apps\perch_twitter\PerchTwitter.class.php:163) in C:\inetpub\dev\admin\core\lib\PerchUtil.class.php on line 1406

Warning: Cannot modify header information - headers already sent by (output started at C:\inetpub\dev\admin\addons\apps\perch_twitter\PerchTwitter.class.php:163) in C:\inetpub\dev\admin\core\lib\PerchUtil.class.php on line 1407

Warning: Cannot modify header information - headers already sent by (output started at C:\inetpub\dev\admin\addons\apps\perch_twitter\PerchTwitter.class.php:163) in C:\inetpub\dev\admin\core\lib\PerchUtil.class.php on line 1413

Warning: Cannot modify header information - headers already sent by (output started at C:\inetpub\dev\admin\addons\apps\perch_twitter\PerchTwitter.class.php:163) in C:\inetpub\dev\admin\core\inc\top.php on line 17

top.php looks like this in this system:

<?php
    $Settings->get('headerColour')->val();

    PerchUtil::set_security_headers();

    // Check for updates
    $update_setting_key = 'update_'.$Perch->version;
    if (PERCH_RUNWAY) $update_setting_key = 'update_runway_'.$Perch->version;
    if (!$Settings->get($update_setting_key)->val()) {
        PerchUtil::redirect(PERCH_LOGINPATH . '/core/update/');
    }

    // Help markup as used by apps etc
    $Perch->help_html = '';
    $help_html = '';

    header('Content-Type: text/html; charset=utf-8');

    if ($CurrentUser->logged_in()) {
        include(PERCH_CORE . '/templates/layout/top.php');
    }else{
        include(PERCH_CORE . '/templates/login/top.php');
    }

And the function out of PerchUtil.class.php that it seems to be complaining about is from Lines 1402 to 1414 of that file:

        public static function set_security_headers()
        {
            /* https://www.owasp.org/index.php/List_of_useful_HTTP_headers */
            header('X-Frame-Options: deny');
            header('X-XSS-Protection: 1; mode=block');
            header('X-Content-Type-Options: nosniff');

            if (defined('PERCH_SSL') && PERCH_SSL) {
                header('Strict-Transport-Security: max-age=31536000; includeSubDomains; preload');
            }

            header_remove('X-Powered-By');
        }

Does any of this suggest a reason why the issues would be occurring? Is there something else that I should look into?

Right, so we're back to where we started again. Do you have any additional points of investigation I should look into that aren't apparent in the diagnostic details? Something that the client does not have installed or does not have enabled?

Sorry for the long delay in response. But I'm afraid to say that the client has decided to take the work off the table for how problematic it has been to try to get the perch twitter app running on their server. Thanks for sticking with me on this Drew, and apologies for leaving you hanging for the last two weeks.