To clarify, clearing the cache didn’t resolve the staging URLs on production issue.

Negative; Publisher.

Yes, although core_template_route starts on line 933 in the copy I’ve got; looks to match up otherwise…

<pre><code>public function core_template_route($uri_string) { $last_call = NULL;

    if (ee()->extensions->last_call)
    {
        $uri_string = ee()->extensions->last_call;
        $last_call = $uri_string;
    }

    // Don't muck with the URI or templates
    if (PUBLISHER_LITE && $last_call)
    {
        return $last_call;
    }

    if (PUBLISHER_LITE)
    {
        return;
    }

    $parts = explode('/', $uri_string);[/code]

Updated; New Error:

Message: Undefined variable: url_string Filename: publisher/ext.publisher.php Line Number: 956

Am I correct to assume it should be $parts = $uri_string, and not $url_string?

Alright, have this in place now, and the PHP error is gone:

if (is_array($uri_string))
        {
            $parts = $uri_string; // changed from $url_string
        }
        else
        {
            $parts = explode('/', $uri_string);
        }

Still have the issue of the incorrect paths within the links though. Perhaps the path was cached somewhere? Have cache disabled and time set to 0, and am not using any template or tag caching.

We’re basically getting the {site_url} value for staging instead of production from the {pagination_url} tags in the {paginate} loop, but only on page 2 and beyond (if there’s a pagination segment in the URL of the template rendering the loop, it breaks, I think).

Our setup:

• Dev: http://staging.example.com/~user/www/
• Staging: http://staging.example.com/
• Production: http://www.example.com/

On production, we’d want to get a link to this page:

• http://www.example.com/news/P10/

Instead, we’re getting this:

• http://staging.example.com/news/P10/

When I’m in my dev account (shares same DB as staging) I’m also getting the staging URL’s.

Hopefully that makes sense; the presence of the pagination_base parameter doesn’t make a difference, if that’s of any use.

• Publisher’s cache is disabled; set the time to 0 to be safe.

• Re-ordered a page in Structure.

• Cleared all caches in EE for good measure, although we’re not using any of EE’s tag/template caching.

… and still broken, unfortunately.

We are running a custom config with environment detection and path setting, but, it’s been working without any issues for a quite a while, and, our paths are fine everywhere except for the pagination links on page 2+.

The output there looks A-OK:

array(2) { [“open”]=> array(5) { [1]=> array(1) { [1]=> array(3) { [“uris”]=> array(710) { [524]=> string(8) “/contact”

… and so on. Where the URL is getting dumped out, I’m seeing the correct path: http://staging.example.com/~user/www/

There aren’t any problems with {site_url} anywhere; I was attempting to explain, perhaps poorly, that the “value of {site_url}” is what appears to be incorrect in the pagination links that are being generated.

Again, the issue is only with the value of {pagination_url}. {pagination_url} is pointing to an address on the staging server, not the production server. This only happens when the template is rendered at a URL including a pagination segment - /foo/ will build the {pagination_url} links just fine; when you go to /foo/P10, then all of the {pagination_url} links will point to the wrong server.

Per my original post to Structure’s support: “When I set Publisher’s “Enabled Publisher” setting to “No,” the problem persisted, so, I’m positing it’s a Structure issue.”

Tried disabling Publisher again, still no dice.

As far as other add-ons that might be interacting with pagination or pagination segments, we’ve got the following:

• Seg 2 Cat (I think this has some category ID tag that URL helper didn’t, which is why I’ve got both)
• URL Helper
• Page Number ( https://github.com/tyssen/Page-Number.ee_addon )
• Structure

I think that’s it; the pagination loops themselves are pretty vanilla.

The other dev here noticed that the page URL arrays in exp_publisher_site_pages contains the staging URL, and that there were potentially similar issues getting discussed here? - https://boldminded.com/support/ticket/503

Thoughts, any?

To followup, the place where the staging URL shows up in the DB, at least in plain text, is within exp_publisher_site_pages (for some reason I ran the update for Publisher while in the control panel for staging, and not development; while there are paths elsewhere in the DB, they’re all paths to my dev folder there).

I also updated my config.php to change the path to the staging server to see if that would alter the behavior - it didn’t.

But… when I uploaded an older version of Structure back to the server, the pagination links were fixed, so, appears this is on Structure’s end (possibly having trouble with data from Publisher, as I don’t know where else the staging URL could be coming from).

Appreciate the back and forth on this; at least we got that PHP bug fixed 😊