Joomla 3.5: page displayed source until cache is cleared - php

I have a weird issue where the browser returns the unformatted source code of the requested page instead of the html. The content type is set as application/rss+xml when it should be text/html. I'm running Joomla 3.5.1. As far as I know, there are no RSS feeds for the site.
This is resolved when clearing the Joomla cache, however, I haven't been able to find a way to replicate the issue so it's proving difficult to debug.
I'm not sure what other information I can provide.
Any ideas would be great.

This is an odd problem. The fact that the backend is running fine and that "sometimes" the frontend has this problem (while the backend is fine) makes it more complicated. Does the problem happen if you disable the cache completely on your Joomla website? Also, is the problem happening on all the pages?
I suggest the next time you have this problem is to contact your host or your developer immediately, and hopefully they will be able to fix the problem. It's very hard to suggest a solution here without more context.
Note: If you were able to solve it, then please post back the solution here as it will help others.

Related

My website's cache stopped working randomly

On my website some user started to experience very slow page loading on PC but fine on cellphone. I tried going into Incognito mode, it was very slow even thought before (2-4 weeks) I went on my site on Incognito mode and it was working fine. I then cleared my cache, and now even my normal chrome browsing is slow.
Do anyone know what could have cause this? No one touched the code for a month.
Also if anyone have a suggestion on how I might be able to fix this, it would be very appreciated.
Thank you,
Jessie
Answering just to mark it as answered.
The problem was a .js link which wasn't valid anymore (captchme-interstitial-min.js) that was in my header. removed it from the code an now everything is good!
Thanks to p0358 for the big help

Error when loading scripts in Wordpress admin

I am using Wordpress Images Gallery and each time I try to add new images I get this error in the console:
GET ...
wp-admin/load-scripts.php?c=0&load%5B%5D=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sorta&load%5B%5D=ble,thickbox,underscore,shortcode,backbone,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-plupload&ver=4.9.8
net::ERR_CONNECTION_RESET
Everything worked perfectly until recently and I really don't know what could be the cause. I do not have a lot of experience using Wordpress, so I am not sure what other information could be relevant. Also, the error seems kind of vague to me. I will provide further details if required.
I suspect there are too many scripts to load and that gives the error.
Thank you.
I disabled script concatenation in config and everything works. Thanks.

Joomla makes my request wait for 5 seconds

I have got a very strange problem regarding one of my Joomla websites. The webpage seems to wait before it loads the actual content. So I did some research and I found out that there is a particular file (index.php/en/) that makes my request wait for over 5 seconds. See the image below.
https://imgur.com/JqlkNYq
I run on the latest version of Joomla and I haven't got any issues on other sites with plugins or components (DJ Imageslider is the only component here) so I'm really confused in where the problem can lie. I'll keep researching the problem but I hope someone may have had the same problem that can help me with this issue.
Ok, I fixed the issue. There was a module which was completely not loading anymore and giving multiple errors. With the use of debugging in the Joomla website I could track the issue.

Drupal site setting `Content-Type` to `application/x-gzip` all the time

I am in the process of migrating an existing Drupal website from another provider to Bluehost.com -- while I think using Bluehost.com is not relevant in this context I thought I'd mention it anyway, in case there are indeed some particularities I'm not aware of.
The site is a Drupal 6 installation and it did work previously I am told on bluehost too so you think it shouldn't be any problems, however, having copied it over I encounter a big problem: all the responses from Drupal are sent with Content-Encoding set to application/x-gzip. This has the implication of all browser presenting a download dialog box rather than rendering the content.
I have actually curl'd the index page and ran it through gunzip and the output is the correct HTML for the site -- just that it somehow ends up being gzip'd and this mangles the content type and confuses the browsers.
Talking to previous maintainers of the site they suggested using PHP 5.4 (they were running it on php 5.5 as I understand and despite all the Drupal suggestions it was running perfectly well I'm told).
I am trying to eliminate now any type of gzip'ing that occurs here so I've got it down to a few layers which could cause it but eliminating those it still doesn't work:
SetEnv no-gzip 1 in .htaccess
zlib.output_compression = Off in php.ini
drupal had the boost module installed and some corresponding settings in .htaccess -- i've removed those from the .htaccess file as well as deleting the boost directory from sites/all/modules
The problem still stands and my files are being sent to the browser compressed. Is there any other way to disable this?
Note that this only happens for pages inside Drupal, having uploaded a simple php page and navigate to that url works fine -- which suggests therefore a drupal (rather than apache/php) problem.
I've noticed a module mimedetect which has a definition for application/x-gzip in there but not sure how could this affect it as removing this didn't render anything useful either.
Any ideas where to look and/or what might cause it?
Happy to provide any other insights that might be useful in diagnosing this.
Ok so having actually reset the database cache and with the settings above this now works. I'm trying to figure out which one of the above actually solved it.

Webpage consistently didn't work the first time it was loaded. Why was output_buffering causing problems?

I want to share a problem I had, the fix I found and then ask a question about the reason behind the fix.
The problem
After upgrading to wampserver 2.2, one of my webpages consistently didn't work the first time it was loaded in the browser. This happened with internet explorer, chrome, firefox and safari. When reloaded the page worked in all browsers.
the fix
I decided to implement a better debugging solution and while doing so inadvertently fixed my problem. When I set output_buffering =On in php.ini the page worked correctly.
my code
I'm not going to go into detail here. I'm more interested in theory for how output_buffering could be causing problems. Also I think my code will be more of an eyesore than a help.
I used ajax and joomla sessions (external script) to retrieve
information for the page.
I believe that when output_buffering was off, the joomla session
was not able to retrieve values. I'm not able to confirm this yet
though.
My question
In what ways can output_buffering= Off adversely affect code? Why?
Output buffering simply allows you to hold off on displaying data that would otherwise be immediately printed to the browser. These are used largely with templating engines in order to store unrendered templates so that they can be filled in with values. I'm guessing Joomla depends on output buffering to fill in the correct values for its templates, which would explain why you were seeing invalid output.
"I used ajax and joomla sessions (external script) to retrieve information for the page."
That is your problem. You're retrieving a content that varies within a certain time delay.
Refer to this, it may help you understand how it works: https://stackoverflow.com/a/2832179/817419
As it turned out one of the files being called by the webpage was encoded incorrectly. Once I encoded it as UTF8 without BOM my problem was largely fixed. My script would work without output_buffering turned on.
The other part of the problem was that some of the scripts that used Firebug complained of headers already being sent. This stopped the code in its tracks.

Categories