Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Publisher resource hit on domain change

Status Resolved
Add-on / Version Publisher Lite 3.1.5
Severity
EE Version 5.3.2

James Brown

Jul 30, 2020

Last night we moved our staging server that we had been working on with a new version of our site to production. This just involved changing the site url values in the control panel and changing the internal web server pointer to point to the staging server. When we did this we had a massive load time hit to the point where the site was un-useable. The site had been running on the same server just as staging for a couple months during development and testing without any issue. After a lot of frantic digging we traced it down to Publisher Lite. In many instances the Publisher Session Start time was well over 8 seconds. Luckily we discovered the cache setting in the control panel which did bring those times back down to normal. But I had some questions based on what I could find in the documentation and labels in the UI.

1. Does it strike you as odd that the same server but just changing the domain name would all of a sudden cause a huge uptick in load times? This was during the night when there’s pretty minimal traffic.
2. On the cache settings page it mentions that it caches a lot of stuff related to translations. We are just using Publisher Lite, so we don’t even use translations. I did see that there were a number of queries on the page related to translations. Is there any way to disable those?
3. It mention “to cache entries you must add the publisher_cache tag, e.g. {exp:channel:entries publisher_cache="yes"}”. I wasn’t quite sure what it was saying would be cached with this. I didn’t actually put it in, but when I turned caching on, it definitely sped things up. So I was confused what that does and if I need to do it.
4. I noticed a rather large cookie attributed to Publisher, exp_publisher_tracker, with a size of 620. That’s pretty large for a single cookie. Is there any way to disable that?

Any other performance gains I can try? I’m just running Publisher Lite to be able to do Drafts and be able to share previews of Drafts. I do use Speedy as well for static caching. I love that someone picked that up!!!

Thanks!
James

#1

BoldMinded (Brian)

1) Publisher doesn’t care about domain name. If the files moved location on the server, then that makes sense b/c if you’re using file based caching then the cache has to be re-warmed. It has to cache phrases, which does use quite a bit of queries (this happened after I switched to using EE’s models to manage phrases). I’ve been meaning to see what I can optimize with phrases.

2) After you mention this I’m surprised that I didn’t try this sooner… in ext.publisher.php, line 787 or so, add the conditional mentioned below and see what it does.

public function channel_entries_query_result($channel, $results)
    {
        $this->benchmark->start('channel_entries_query_result_hook');

        if (ee()->extensions->last_call !== false) {
            $results = ee()->extensions->last_call;
        }

        if (App::isFeatureAvailable('livePreview') && ee('LivePreview')->hasEntryData()) {
            $this->benchmark->stop('channel_entries_query_result_hook');
            return $results;
        }

        // Add this conditional 
        if (PUBLISHER_LITE && $this->request->isCurrentStatusOpen()) {
            return $results;
        }

3) Adding publisher_cache=”yes” just means it caches it’s query results, but the above conditional may negate the need for that.

4) I’ll take a look at this. I’m not a fan of the tracker cookie. It just keeps track of the last X pages visited to assist with the language switching.

#2

James Brown

Thanks for the response Brian.

  1. Hmm. Well no files were actually moved. And while on staging, Speedy caching was off most of the time. We only turned it on near the end of testing. We also don’t have Speedy caching automatically rebuild. We just have it build on page load. But if you were referring to the Publisher caching, we didn’t have that turned on in staging or production. We only turned it on once the site wasn’t loading and we figured out something was up with Publisher. That’s why it was a bit of a mystery.

  2. Thanks! I’ll give it a try this evening and see how it goes.

  3. Ah ok. Interesting that the caching seemed to be working well without the tag.

  4. Yea, would definitely be nice to at least have the option to turn it off. It’s a big cookie load to carry around.

#3

BoldMinded (Brian)

Regarding the tracker cookie. Open up the Service/Url/Tracker.php file, and on line 44 change the limit to 2, and see what that does. The reason it exists is b/c at times Publisher needs the previous/referring URL, and at least at one point in time, ajax requests would be the HTTP_REFERRER value, so if someone had an ajax request happening and tried to change the language at the same time, it would get totally confused and not redirect correctly. It really only needs the previous value, so setting it to 2, maybe even 1, might still work fine. Let me know what your results are with this change.

Login to reply