I'm not much of a server guy so I was wondering if anyone here would know of a basic apache/mysql configuration detail to look for to explain why a cloned wordpress site in one environment would be encoding all ampersands on save when the same site in several other environments doesn't. There's not a whole lot special about the code. It's pretty much raw wordpress and ACF for custom fields.
I'm sure it's not just ampersands too, but that's the character we're using to test with. And really, what is happening is a site we built on our local machines was hosted on media temple, then aws, then wpengine, and now liquid web. All previous hosts have had no issues with this, but now with liquid web we have an encoding problem and they insist this is unrelated to their server configurations, and refuse to help diagnose the issue.
I can run phpinfo() on my local and the liquid web servers, but I am not sure what I would be looking for. Anything that would be auto encoding post values? Not sure. Also not sure if this would be a mysql configuration thing.
Any thoughts?
Naturally, we found the culprit minutes after posting this. Here it is in case anyone else has this issue:
in the wp-config.php file we noticed this:
define('CUSTOM_TAGS', true);
Evidently, this runs the wp_kses function on post input. We didn't add this to the config file, but considering plugins can modify this file, it is plausible that we had tried out plugins for things and decided against them, and upon uninstall, the plugin didn't clean up after itself.
Who knows how this can end up in the wp-config.php file, but it did. So if you experience the & bug, have a look there.
Related
I've got a small experimental project on the go that uses an embedded system to show web pages.
The major draw back is that the embedded system doesn't have any form of server on it (No lovely web server languages allowed).
My current setup for testing any potential winning solution is locally (Just in a document C:/users/me/test/index.html) and then also testing it in wamp.
I've looked into using JS or JQuery but evey resource i've found only ever works when I test it within wamp, which isn't a viable solution for me.
I have a couple of questions:
Is it even possible to read an XML document without any form of
server technology?
If so, could someone post some resources please? I've found a lot of similar topics to mine, but none really cover my predicament.
If this isn't possible, are there any other technologies I could use to give the same output?
Thanks
I've installed the latest MediaWiki and the latest Visual Editor, everything is looking great but I have one problem though. All my uploaded images cannot be searched when adding media to the article. Can anybody please enlighten me.
Things are in flux (some tweaks were needed after CirrusSearch), but VisualEditor's MWMediaSearchWidget uses the srsearch API.
In MediaWiki defaults, this will be a simplistic full text MySQL search, which doesn't do stemming or anything hence is very likely to miss results compared to CirrusSearch.
Additionally, and perhaps more importantly (depending on your wiki), it won't include media from remote repositories like Wikimedia Commons. I'm not sure what to do in that case, perhaps the widget should be modified to (also) query the remote repository's API.
I'm making a website, and I like testing everything offline instead of having to upload files with every change I make. The problem is I can't use includes, so when I do upload, I'm going to have to change a lot of the file structure.
I'm not looking to install a local server like WAMP when I just want to use includes. Is there any way?
Not really.
You could process includes statically (e.g., write yourself a Makefile to create the actual HTML files you view locally). There are plenty of template languages out there that could do this. You could, I suppose, even write your templates in JavaScript and let the web browser assemble them.
But really, why wouldn't you want your test environment to match your production environment? This seems silly—if there is something wrong with your includes, you want to find out before you make it live. If you accidentally get a local path to an image (C:\Documents and Settings\…\image.png) in a file, you want to find out. The best way to do this is really to run a webserver locally.
I want to add my own text and change the template of the default hudson for authenticated users.
where are the html files located so I can edit them ? or is there another solution ?
Have a look at the war directory, after you started Hudson for the first time. There you should find all the components that are used (css, images, and scripts). Have fun changing them.
However, I would expect that your changes will be gone after you upgrade your Hudson server. You might be able to get around this problem by writing your own plugin.
Let us know, if you get it done and what the solution is.
In a HTML page references to Javascript files are rewritten with one additional subdirectory at the end:
/+sfgRmluamFuX1R5cGU9amF2YV9zY3JpcHQmRmluamFuX0xhbmc9dGV4dC9qYXZhc2NyaXB0+.
Why is that and can it be a source to potential problems?
In our source code we have Javascript includes like this one:
On development machines and the test server everything works fine. However, when installed on a production server, the code is somehow changed and looks like this one:
This is for every script. Since we are experiencing problems with some of the Javascripts, I wonder whether this can be the cause of them.
I googled for quite a while and did not find any good explanation for this code addition, the only one I found was that this can be generated by a proxy server.
Edit: Proxy issue. See Ivan's solution to his own problem.
Is this really HTML? You wouldn't happen to be in ASP.NET would you, cause that looks alot like a cookieless session string.
You can very easily test to make sure you're scripts are loaded by checking firebug's net tab, or failing that just putting an alert('LOADED!') in them.
We use Java and JSF with JBoss.
Originally the code is like this one:
<script src="/js/tiny_mce/tiny_mce.js" type="text/javascript"><!--
//--></script>
And it gets rewritten to this one:
<script src="/js/tiny_mce/+sfgRmluamFuX1R5cGU9amF2YV9zY3JpcHQmRmluamFuX0xhbmc9dGV4dC9qYXZhc2NyaXB0+/tiny_mce.js" type="text/javascript"><!--
//--></script>
It is definitely a proxy problem. We accessed it from another place than ours and it worked and these funny additions did not appear.
Here's the solution for all the guys that can have the same problem. It was due to our security policy. We added the website into our trusted zone and it was fine.