The text on my wordpress text editor is white on a white background so its invisible for most people..
I searched it and the solution I found was to add the following code to wp-config.php
define('CONCATENATE_SCRIPTS', false );
It worked fine but I couldn't find what it does or why it works.
I only found a question that asks the same thing here but it didn't get an answer.
Could someone explain what the code above does and why it works?
First of all, nice question.
CONCATENATE_SCRIPTS is the constant that tells wordpress to, well.. concatenate all of the dependencies into one URL and load it together ( to save http requests I guess ).
As far as I know, it applies only to the Admin area ( back end ).
The result is a url like
<script src="http://somewordpress.site/wp-admin/load-scripts.php?c=1&load=jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,hoverIntent,common,jquery-color,wp-ajax-response,wp-lists,jquery-ui-resizable,quicktags,jquery-query,admin-comments,postbox,dashboard,thickbox,plugin-install,media-upload&ver=e0f647a6df61adcc7200ce17a647db7f" type="text/javascript">
This is the normal default behavior, and if you have problems with it, it is probably because of some javascript conflict in theme or plugin.
Another possible ( albeit less frequent ) is a browser problem due to TinyMCE caching. clear browser cache. ( edit : was true to Sep.2015 - not verified since but still worth trying )
If you really want to see where it is defined or what is it doing you can look here.
Anyhow, by defining the constant as false you are practically forcing WordPress to load each script on the administration page individually rater than collectively.
So in that case - If one script fails to load and work correctly, the others can still continue to operate correctly.
This is a recommended setting for debugging and local development.
However, in your case, it is a symptom of a problem, and not the problem itself. you should isolate the problem and fix it ( probably a plugin like said before )
To expand upon Obmerk's answer, in my case setting CONCATENATE_SCRIPTS to false simply enabled me to see the individual failure in the browser console as it then showed the javascript for tinymce was not loading properly. Then looking at server logs showed that wp-tinymce.php was not executing properly. In the end, I needed to fix the permissions of {sitepath}/wp-includes/js/tinymce/wp-tinymce.php so that the security settings of the server I was on would allow it to run.
In my case the server did not allow it to be group-writable so a chmod 755 took care of it. The actual solution will vary based on your server configuration.
Related
Previously working code that downloads a csv file from our site, now fails. Chrome, Safari and Edge don't display anything helpful except "Blob Blocked", but Firefox shows a stack trace;
Uncaught TypeError: Location.href setter: Access to 'blob:http://oursite.test/7e283bab-e48c-a942-928c-fae0907fdc82' from script denied.
Then a stack dump from googletagmanager
This appears to be a fault in the tagmanager code introduced in the last couple of weeks.
The fault appears in all browsers and is resolved immediately by commenting out the tag manager. The problem reported by a customer on the production system, and then found on both staging and locally. The customer advised they had used the export function successfully 2 weeks ago.
The question really is, do Google maintain a public facing issues log for things like the tag manager?
It's not about GTM as a library really, it's about poor user implementation. It's not up to Google to check for user-introduced conflicts with the rest of the site's functionality.
What you could do is go to GTM, and see what has been released in the past two weeks. Inspect things and look for anything that could interfere with the site's functionality. At the same time - do the opposite, see all the front-end changes introduced during this time frame by the web-dev team.
Things to watch for is mostly unclosured JS deployed in custom HTML tags. junior GTM implementation specialists like to use the global space, taking the global variables, often after the page is loaded, thus overwriting front-end's variables.
Sometimes, people would deploy minified unclosured code to the DOM, thus chaotically taking short var names. To the same end.
This is likely the easiest and most common way for GTM to break front-end. There definitely still are many ways to do so besides this though.
If this doesn't help, there's another easy way to debug it: make a new workspace from Default (or whatever is live), go into the preview mode and confirm that the issue still happens. Now start disabling newest created fired tags one by one and pinpoint which one causes the issue.
Let us know what it was.
Solution was to replace the previous tag manager code with the latest recommended snippet
I am using the Magento WordPress Integration plugin to call blocks from a parallel Magento installation in order to pull the appropriate menu blocks from Magento.
This is working very well except for one thing, the sites are multilingual.
I have inserted some code in Wordpress so that when the language is changed, it changes the store cookie to the appropriate language, in hopes of ensuring that Magento loads the menu in the right language.
This works perfectly except it requires, for some reason, two clicks before it loads the correct language. I can see in the web inspector that the 'store' cookie is set to the right language, but the plugin seems to be loading the Magento content before this happens somehow.
I'm really at a loss for what to do besides separating the menus and having them manually coded between systems. I was in discussion with the actual developer of the plugin but he was unable to think of a solution himself (unfortunately the discussion was terminated when I asked for the possibility of contracting some support).
In any case, if anyone has any idea how to go about this I would so deeply appreciate it as it seems no one out there has found a solution for what I would have imagined was a rather typical setup.
--
edit: this is what I've written so far and am trying to get to work. It pulls the language string from the URL and then sets the store cookie. By looking at the Plugin API/Action Reference it is the first thing that occurs in the load order. I do have a must-use plugin and can confirm it works, but also I've tried hooking it to registered_taxonomy, post type etc... For some bizarre reason it still doesn't work until the second click even though it happens far before the theme or the regular plugins load.
function set_store_cookie() {
if( preg_match("(/(de|en|jp)/)",$_SERVER[REDIRECT_URL],$m)) {
$pbCurrentLanguage = $m[1];
} else {
$currentLanguage = "en";
}
setcookie('store', $currentLanguage, time()+(60 * 60 * 24 * 1), COOKIEPATH, '.domain.com', false);
}
add_action('registered_post_type', 'set_store_cookie');
--
Edit 2:
After extensive talk with Mihai below, we discussed a number of things but found primarily that no matter what, if the store cookie is set, Wordpress loads the language specified by the cookie even if statically calling $app = Mage::app('desired_lang', 'store');
This gets really confusing because it falls into the same issue as before: if the cookie is set, Wordpress fails to load the appropriate Magento language until the second refresh.
I've solved this in the meantime by deleting the cookie every time Wordpress is loaded, but this seems really to be an non-ideal solution. It is so baffling to me that even calling Mage::app statically loads the wrong language and is overridden by the cookie (and on the next load too)
The Magento ==> WordPress bridge plugin initializes Magento at some point. At that point Magento can be loaded by specifying which website or which storeview you want to load.
This happens in the plugin file: wp-content/plugins/magento-wordpress-integration/mwi.php on line 53 where you have the following code:
$app = Mage::app(self::getValue('websitecode','base'), 'website');
The first parameter (self::getValue('websitecode','base')) fetches the website code (short name) of the website to be loaded. The second parameter specifies the fact that the first parameter is a website code not a storeview code.
You can rewrite that line as such:
if(isset($_SESSION['storeviewcode'])) {
/**
* Loads a particular storeview that you specify in
* $_SESSION['storeviewcode'].
*/
$app = Mage::app($_SESSION['storeviewcode'], 'store');
}
else {
/**
* Falls back to default behavior.
*/
$app = Mage::app(self::getValue('websitecode','base'), 'website');
}
I assume you know but for completeness Magento storeviews are usually used for translations, they have the specific locale associated with them.
All you need to do is:
Find out during which WordPress event (hook) is Magento being loaded;
Find out which event occurs right before Magento is being loaded;
Write some code that initializes $_SESSION['storeviewcode'] with a valid storeviewcode;
Attach the code to the proper event (hook);
Make sure the WordPress languages correspond to the correct storeviewcode;
I can't answer the question just yet, but I can't leave a comment either. However, could you confirm to me the cookie settings you've used in the admin area of Magento? (System > Config > Web)
OK. Well Mihai, James (plugin author) and I spent hours chatting and trying endless possible solutions and none worked.
No matter what, Magento kept overriding any manually requested locale with the cookie value.
The issue is that the correct cookie value was never read until the subsequent reload.
My initial solution, as in the edit, was to unset the cookie each time Wordpress was loaded (not ideal) and manually call the locale via Mage::app.
Finally, I decided to look at it from a PHP standpoint rather than Magento/WP after Mihai mentioned how frustrating session/cookie implementation can be in PHP and came across this thread: http://www.webmasterworld.com/php/4332059.htm
In the end it was a simple one-liner of adding:
$_COOKIE['store'] = 'new_locale'
after setcookie(...) to ensure the current cookie variable matches that of set cookie without requiring a second page load. This code was hooked into Wordpress via add_action('muplugins_loaded', 'set_store_cookie');, the earliest possible in Wordpress' action order.
No modifications were, in the end, necessary to Magento, Wordpress nor the WPI Plugin.
While it doesn't solve the question of why Magento was overriding manual app calls with the cookie, it does work properly now finally. It appears there is actually a bug with Magento: https://gist.github.com/Vinai/1205913 - even though this diff didn't correct the behaviour either.
Endless thanks Mihai and James, this was such a painful issue to try to sort out.
I'm having a heck of time trying to get comments to post to my nodes. I've done all the obvious:
Enable comment module,
set appropriate permissions,
etc.
But every time I try to enter a comment it simply redirects to a "Add new comment" page and nothing gets posted. There is no comment in the Content -> Comments section and my database comment table is empty.
The only thing I can find relating to the issue is an error report in my log messages which displays a warning "page not found." I'm using the Drupal Busy theme.
Type: Page not found
Location: http://mysite/public://color/busy-0970ccd8/style.css?m
Message: public://color/busy-0970ccd8/style.css
Severity: Warning
I've ran the schema module and nothing is funky in with my database. Any thoughts on this? Much appreciated.
It's looking for a stylesheet from the Color module. It would normally be at sites/default/files/color/busy-0970ccd8/style.css
Do you have a sites/default/files directory? Check that you have one at that the directory is writable. Also check to be sure that the color module is enabled. Save your theme settings and clear your cache in configuration -- performance.
I'm not sure if a problem retrieving a style sheet from the color module could be causing this. Seems very unlikely.
You might consider not using the busy theme. It's current status is "minimally maintained" and the theme authors have left a note on the project page that there will be no further development at this time.
I recommend looking for a theme that is actively maintained and has good support. It looks like Busy is a pretty standard 960 grid, you might like Omega.
Today, I got free hosting space from my internet service provider. So, to test my Drupal project, I installed Drupal along with all those necessary modules (views, imageattach, Private message, search). Everything seems went well, until I tried to create a view.
When I add view and fills out all necessary field and press next, it just shows a blank white page instead of the "Views UI" edit page. I checked back in the view's list page, but no view was created. I'm not sure what causes this to happen;so I much appreciate your help.
Drupal 6.x
View 6.x-2.11
Private Message - 6.x-1.3
Note: It works fine in local environment.
UPDATE : As WmasterJ suggested, I checked dblog and found that my custom module is sending header inadvertently - there was gibberish(inverted question mark) just before my opening tag. I don't know how it got there. But, anyway, I removed it and the problem solves. Thanks WebmasterJ and the rest for helping me out.
Cheers
PS : WmasterJ, just want to let you know that, I tried to clicked on check mark to indicate your post is the solution, but it doesn't work at all. "Add comment" link doesn't work either. So, don't be surprise for not seeing any indication of yours being the right solution.
Some tips from the "white screen of death" page that mattv posted which I would try is:
First, try and get some error messaging out there since this will help you to pin-point the problem and solve it faster. In you index.php file write:
<?php
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
// $Id: index.php ...
Second, take a look at messages in your watchdog log at: /admin/reports/dblog
After which you will have a better understanding and can go back to the white page of death help page and read more.
There is a whole page in the Drupal handbooks dedicated to debugging the "White Screen of Death". In a nutshell, enable error reporting and check the logs. Those two steps tend to pinpoint the problem, most of the time. If that doesn't point you towards a solution, continue down the handbook page, for lots more tips.
If I had to take a wild guess, I would say your case is probably an out-of-memory error.
If it's free space from your shared ISP, chances are you're out of memory.
Create a PHP file that contains only the following:
<?php
phpinfo();
?>
Load it in your browser (if you called the file "info.php", go to http://www.yoursite.com/info.php) and look for the line that says memory_limit. If it's less than 32MB, that's what's causing it - it's why the site works fine locally and most pages work fine, but the View create page takes up a lot of memory.
Also try going to the Modules page, this page can also consume a lot of memory - if you get a white screen there then this backs up the out-of-memory theory.
Your ISP may let you override the memory_limit by creating a php.ini file somewhere in your account. You should set it to at least 64M, preferably 128M+ for a complex site.
Whenever we make changes to the CSS, it generally takes 24 hours to reflect those changes on my site. I have tried clearing the server cache and browser cache but it doesn't help too. Is there any other way to make the CSS changes reflect immediately after updation?
it happens in all the browsers... when i check it in the browser , i can access my css file with two paths eg : i store my css in folder named "Cssfolder" and my css name is say 135.css
So when i access the folder paths, Cssfolder/135.css & cssfolder/135.css, one of the path shows me latest css whereas other one shows me old css.Notice the "c" is captital in one path whereas small in other path.
Thanks.
I've found this to be a pretty common problem in a lot of my projects. I would suggest two things...
If it's just an app that you are working on you can use the CSS Cachebuster during development.
Following the idea behind the Cachebuster I have found that often adding the timestamp of the CSS file as a query string off of the CSS link will help in telling the browser that the file is different... something like... whatever.css?12212009035543
You might want to use a monitoring tool, like Live Http Headers for Firefox, to see the requests and responses to and from the server. This usually solves a lot of problems for me. Take a look at the "Expire" headers and conditional requests (like: "If-modified-since"). This said, take a look at server and client local times and timezones - it might be that they differ significantly and conditional GET requests "seem to be" handled correctly, because of future or otherwise mangled timestamps.
You can force to load the current css directly from the server with appending a random unique value to the url, like http://example.com/Cssfolder/135.css?983274928374 and http://example.com/cssfolder/134.css?08973249827. There's no way that this would ever get cached unless you use the same random value twice.
This way you learn where to look further for the solution to your problem: At the server, the ISP/a proxy or your browser.
You really need to see whether this is server side or client side. If the server is still serving the old CSS then clearly you've got no chance on the client side.
I've occasionally seen times where I've had to show the CSS in the browser, and then next time I've been to the real page, it's used that new CSS. Usually just hitting refresh does it.
Do you have any web caches like Akamai involved anywhere?
If you try to go to the CSS page from a computer which has never seen the old version, which version does it show?
EDIT: Changed answer to reflect edits in question.
I have been dealing with this issue in the past, and ended up writing a httpmodule to deal with it.
It's pretty simple, it just finds all script/css links in head tag (they now need to have runat=server) and appends the assembly version number to the link, in the same way as Tim K describes. This way im sure my clients always fetches the newest css/scripts when my app is updated in production, and never have to deal with this issue again.
Maybe Internet Service Provider cache, as in this case?
I was perplexed by this issue then someone said Ctrl+F5. Worked for me :)
When I am developing and I need to be sure that I am seeing changes as I work, I stick the css in the page ie
<style type="text/css">
/* your css */
</style>
Or you could constantly change the name of the css file itself, not very useful in a production environment, but perhaps okay while developing.
I know it doesn't solve the problem, but for developing it is okay.