Most of the times, when I want to send a form with CKForms, the plugin does not recognize it and I get a blank page.
The HTTP Post definitely arrives at the server, I can see that in the Logfiles. When I use another Form Plugin (proforms) the same thing happens.
I'm pretty sure that the problem has something to do with caching! I disabled caching in the joomla backend (in the Server configurations menu and in the Plugin menu) and even tried deleting the cache calls in the plugin file.
I am running Joomla 1.5 on a Apache2 Server.
Could the solution be to disable Caching for this Plugin globally (maybe in the Apache Configuration)? And if so, how can I do this?
Thank you!
Apache has nothing to do with Joomla caching.
The plugin's output may be cached by both the page cache and the component's cache, depending on which event it runs.
CKForms has a good reputation, and having two components throw the same error brings the attention away from them.
Are you using some non-ascii characters in the form names/fields? Does the Joomla contact form work? Is your system clean (no malware etc.)?
The blank page means Joomla encountered an exception / error and didn't finish rendering the page. The information about the error is available in the server php log (not apache error_log, I mean the php error log). You can find the error log location looking it up from the tools/ system information menu in the Joomla administrator or looking at your php.ini. Beware, some hosts have it disabled and you need to turn it on explicitly.
This will contain the error thrown, the file that threw it and the line with the offending code.
Joomla cache has a mechanism to replace the token which now and then broke in older versions, make sure you're using a patched up 1.5.26 version.
Needless to say, your error would also be fixed with an update to 2.5 or 3.x and you should consider it as Joomla1.5 has been dead for a while now.
Related
I'm recently getting back into programming after taking a break for quite some time. I'm currently trying to rebuild my CakePhp 2.X apps for CakePhp 4.X. I'm developing in a local environment using Bitnami WAMP stack.
The issue is that development is very slow because changes do not seem to be taking effect immediately. I have tried disabling all caching by using
Cache::disable();
I've tried placing this line in various places
config/boostrap.php
config/app.php
config/app_local.php
src/application.php
How this is impacting me: I'll make an update, for instance, to a model table file or controller file. I'll go refresh my site to preview the change and either there is no update or there might be an error. To fix the error, I try to undo the changes I made. I go back to my browser and hard refresh the page. I continue to see the same error for 10+ minutes. This often leads me to wanting to undo previous steps but I know that those previous steps didn't cause the issue and it was only the most recent change that caused it. It's making it difficult to keep track of what changes are causing issues and what solutions are working. Even something as simple as updating my navigation element (templates/elements/nav.php) to add a new link does not show on the page when I refresh. I've also tried clearing my browser cache (I use Chrome).
Did you try to clear all keys? You can do it with:
// Will clear all keys.
Cache::clear();
Cache::disable() should work also.
You can also delete the contents of /tmp/cache/ if the caching is set on File.
Maybe the problem is Bitnami WAMP itself. Try to disable the server cache:
https://docs.bitnami.com/installer/infrastructure/wamp/administration/disable-cache/
If you are developing on top of an AMP Stack or customizing any
Bitnami Stack, your files (like JavaScript files) may be cached by the
server and even you modify them your changes will not appear to be
applied.
In order to disable the cache in the server and let the files be
served each time, disable PageSpeed for Apache and OPCache for PHP,
enabled by default
I've been struggling to put SilverStripe behind a load balancer and I've been fixing multiple problems with rsyncing the instances and using shared storage and have almost got it stable, however I've found another issue which breaks the CMS.
Specifically when you try to add a link in the CMS in the TinyMCE editor, when the pop-up screen shows to select the page/file the JavaScript throws an exception that tinyMCE.activeEditor returns null.
I've rsynced the cache directory silverstripe-cache between the two servers and still there is a discrepancy between the m=timestamp of only a few seconds, but I'm guessing this is enough to cause tiny_mce_gzip.php to be forced to load again.
I have a shared redis cache for session storage, shared db, have rsynced the cache directory and use CodeDeploy to deploy the app so it should all be in sync. What other storage areas could cause the different m timestamp? Has anyone had success with SilverStripe CMS being used behind a load balancer without sticky sessions?
You can disable the gzip version of the HTMLEditor. I've seen this happen before. Try adding the following to your config/config.yml:
HTMLEditorField:
use_gzip: false
After that, do a full flush and try again?
Another option, is the javascript not syncing correctly. For that, you'll need to change the way the ?m=12345 is built. By default, it's built based on the timestamp.
I'll see if I can dig up the md5-based one, which might otherwise solve your problem.
*edit
Here ya go, try creating this somewhere in your project, and add the following to _config.php
Requirements::set_backend(new MysiteRequirementsBackend());
https://gist.github.com/Firesphere/794dc0b5a8508cd4c192a1fc88271bbf
Actual work is by one of my colleagues, when we ran into the same issue.
I've had this working in the past (earlier version of Joomla), but must have changed something and I can't get it work (even in a brand new site). I'm using Joomla 3.4.8, the newest version of JCE, and DirectPhp.
I have Global Configuration > Text Filter Settings > Super Users set to No Filtering, and have adjusted JCE Administration > Editor Profiles > Default > Editor Parameters > Advanced > Allow PHP to yes.
Yet, when I save a any article with Php code I get a 403 error. Without the php code it saves correctly.
Does anybody have any hints?
Many of our clients are facing the same problem. It turned out it is related to their host forcing browser caching on non-static content. Please follow the guide here ( http://www.itoctopus.com/how-to-disable-browser-caching-in-joomla-backend ) and add the appropriate code to the .htaccess file to prevent browser caching. Please post back here if it fixes your problem or not.
One way around this that I worked out was to edit the php code in PHPmyAdmin directly.
It seems that mod_security on your apache server is causing the error to be forced when either your code is bad or is restricted. (this is not a bad thing as it stops hacking attempts on your site really.)
Going through phpMyAdmin requires a bit more skill but works all the same.
Anyway that is what I do now when I encounter this issue. (the hard part is finding what is causing the error in the first place)
Probably mod_security is set to block PHP injection attacks, and it sees that as one. The way to tell is check the apache error log and the mod security audit log. Then, if you have access to the config files, you can configure an exception based around either that url or that variable to whitelist it from PHP injection checks.
WARNING: If you do that, be sure the code handling that form will be able to defend itself from injections, because you just stopped apache from defending it.
But the best solution for this is to write a plugin you can invoke from the content item, rather than inject all that code into your content. Makes it easier to maintain -- changes are localized instead of scattered across lots of database records. Change the plugin once and every page that needs it gets the change, instead of having to touch each and every item in the db to make that same change.
PS: There's a Joomla Stack Exchange. Check the list (top right, at time of writing).
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.
-i updated my WordPress today morning to 3.8.1 version , after the update of my WordPress i unable to update any of them and unable to view them in visual field and text field when i press edit my post.
Does the same thing happen if you try using a different browser that you do not normally use? For example, if you use Chrome, try and see if it works in Firefox.
If one browser works but the other does not, then you are experiencing a fairly common caching issue, where your browser is caching javascript files from the old version instead of retrieving the newly updated files.
This happens especially if you have certain types of "speed optimization" plugins or similar code running on the site, because these often create settings to have longer cache intervals for common static files such as images and css and javascript files, to make browsers not have to retrieve as much data. WordPress uses cache-busting version numbers to try to reduce this problem, but these methods are not always effective.
The only solution is to clear the browser cache, but a surprising number of people have difficulties doing that. Browsers are persistent buggers. I recommend clearing the cache, restarting the browser completely (note that some browsers, like Chrome, remain running in the background.. you have to actually kill them manually from the taskbar or similar), and then clearing the cache again after restarting it. Even then, it may take a few attempts.
Alternatively, you may have not have gotten a complete upgrade and some of the files may not be installed. There is a "Reinstall" button on the Upgrade screen that will do a complete file installation over your existing installation. This will not erase any data, it simply gets the core files from WordPress.org and reinstalls them in-place. You can try this to see if it helps. As always, before performing anything like this, make sure you have an up-to-date backup of the site.