I'm having a bit of a major meltdown regarding a translation of a site. It's a wordpress site with a WooCommerce shop. LocoTranslate and Avada is installed.
The issue is, that some individual strings of text are not being translated - even when i've changed the .po file (with PoEdit).
For example, there's a string on the customer cart that says:
"hello USER (not USER? Sign out)"
In PoEdit it looks as such:
Hello %1$s (not %1$s? Sign out)
I'm adding a translation that says:
Hej %1$s (ikke %1$s? Log ud)
It's just not being updated on the site!
Does anyone know what I'm doing wrong??
There are 2 other words that won't be translated either :(
I work a lot with dual language WP sites and find this quite often. In most cases it dues to the textdomain being called before the strings in question are being called. In theory this shouldn't happen but it does. The solution that usually works for me is to add the textdomain a second time in yours functions file and use a hook that runs much later in the site loading process. This invariably fixes it although it a bit of a hack.
If this isn't working and you only need the site in one language you can create a child theme and manually translate the stubborn strings in the page template.
Related
that might seems like an easy question but I'm struggling on this problem since monday.
There's a wordpress website that I need to be hidden when searching for the keywords contained in it, but I can't work it out.
I already tryied to:
Add a robots.txt, on the main root, on the httdocs folder, and on the folder containing the website.
Use the in-built function of wordpress.
Protect the website with a password
None of them seems to be working, so I deleted the website (that was a staging website btw) but it keeps being indexed on search engines.
What shall I do?
Robots.txt is the solution. However you need to realize it can take weeks for google remove the site from index.
For other options see "Make removal permanent" part - https://support.google.com/webmasters/answer/1663419?hl=en
I just wrote a long and detailed question and when I was about to submit it, I fixed the problem by myself. The problem did cost me about 5 hours and now I will just post this little explanation, so maybe it helps others and they will not feel as stupid as I do right now.
In my defense: I do not have that much experience with this system.
What was the Problem? When did it show up?
Before I change a file on the server, I always duplicate it and change the file name to originalFileName_yyyymmdd_hhmm.php (filename + date + time). I want to keep track of the changes, and when we launch the website, I wanted to do a local backup and then delete them from the server.
Let's say, in the folder of the active theme there is a file called home.php.
It is a template file, which means that you can select it as a template for a page when editing it in the backend of WordPress.
I duplicated it and called the new file home_20180301_2300.php.
Then I edited the home.php, but the changes were not displayed on the website.
I checked for any known cache issue, but that was not the problem. So I installed a debugging plugin (Template Debugger) to see which files are used by the server to create the website.
Wordpress used the home_20180301_2300.php instead of the home.php and I did not know why. When I deleted home_20180301_2300.php WordPress did NOT use home.php It just took the standard template instead.
What I think what happened
In the last moment before submitting this question I realized what happened:
In the process of working, there was a situation where I deleted the home.php and then edited the page in the backend. WordPress could not find the home.php, which was set as the template for this page. BUT it found home_20180301_2300.php and used it. (Because WordPress is smart [sometimes {not a joke}]). When home.php was back in its place, WordPress did not care. It looks like as long as there is no problem, WordPress does not search for other (or newer, or better suiting) files. It still used home_20180301_2300.php, because it worked. That's why my changes in home.php did not have any effect. home.php was ignored.
The Solution
I had to delete home_20180301_2300.php, open the page in edit mode and select home.php as the template again. WordPress did not find home_20180301_2300.php, "BUT HEY! There is home.php, my old friend, so I can use it", WordPress said and they happily lived together for the rest of their time.
Feel free to comment!
I am sure my explanation is quite simple and not showing the whole picture. If anyone knows better, I would be glad to hear it. Better knowledge of the problem and the way WordPress works can help me and others to better understand future issues.
Peace out,
Nils
This is odd...
When I create a page (either draft or published) WordPress does its' job by creating/ suggestion a URL File Name.
For some reason it always appends a '-2' (without apostrophes)
So, for example - /exampleABC/ become automatically /exampleABC-2/
At first I thought it was because there was a draft version of the file or one in existence, but that isn't the case.
I've no idea how best to error-check here - any ideas what I should be looking for? Thanks
The current version of WordPress (version 4.5.1) does not have this "bug". Therefore, one of a few possibilities is happening for you:
Possibility 1: You have slug conflicts.
This is the way that WordPress resolves "slug" conflicts. So - the thing that you have to remember is that ANY record in the posts table - whether for a page, post, custom post type, etc - and even media - will have a slug. As #McNab points out - this includes the posts (and media) in the trash. If the slug for the page you are creating conflicts with any existing slug, then WP will automatically append a number (and "increment" it as appropriate):
Saving example - if a post with the slug example exists, will result in a new slug of example-2. If example-2 already exists, then example-3, etc.
Possibility 2: You have a plugin that is causing this issue.
Always keep in mind that plugins can do a LOT, given the power and flexibility of WP, and it's conceivable that a plugin (or your theme) could be causing this.
Possibility 3: Your site is hacked.
Similar to #2, there may be a nefarious / malicious plugin, theme, or "hack" on your site, which is causing this.
However - my strong guess is that it's just possibility 1 - you have other records in the posts table with the slug already existing.
How to know / prove it?
If I were testing / debugging this, I would take the following steps:
Create a page with a crazy, unique page title: "xyzpdqaaa" or similar. Save it. What is the slug? If it's "xyzpdqaaa-2" (aka "wrong"), then possibility one is (probably) ruled out. If it's "xyzpdqaa" (aka "right"), then everything is fine, and you just have slug conflicts.
If the slug turns out to be "xyzpdqaaa-2", then I would disable ALL plugins. (This is a pain, and I hate doing it, but it truly is the way to prove it). Repeat step 1 (with a new "crazy unique" title) - if it's correct, then you've got a plugin causing the problem.
If it is a plugin, start enabling plugins. Typically I work in "halves" - enable HALF the plugins (do your best guess at which one(s) are safe - and enable those first). Test again. If OK, enable more (half of the remaining plugins), test again. If not ok, disable half the enabled ones. (Keep track of which you did / did not enable, so you can narrow down which plugin is causing the issue). Repeat until you narrow down the specific plugin causing problems.
If it's not a plugin (it's still "wrong" even with all plugins disabled), then leave your plugins disabled, and switch themes. Test again. If it's still "wrong", then your site is hacked - clean up the hack. If it's "right", then your theme is the culprit.
Only today that it came to my attention that there is a malicious link that was injected in my wordpress site.
The link is only on the homepage of orphicpixel.com and here is the full code in html
<div class="toggle-search"><div id="5221f63">Learn how to extend your penis size using vigrx reviews.</div><script type="text/javascript">document.getElementById("36f1225".split("").reverse().join("")).style.display
= "none"</script><i class="fa fa-search"></i></div>
This are the fix that I tried.
Change the theme to default - the code is still there.
Turn off all the plugins - the code is gone.
I have identified 5 plugins that when turned on, the code appears. But the plugins are the official plugins like Jetpack, WP-pagination etc.
I search already my database but I got nothing.
I downloaded the theme files and search the codes, nothing
I downloaded all the plugins file and search the codes, nothing
So my last resort is to post this question here.
Unfortunately it is likely hidden in something like an eval statement, which can be hidden in hex. Wordpress can be useful but the plugins are what make a security nightmare. It is likely that some plugin has allowed some kind of upload access to your site and they can run their own PHP script or anything really.
Look through your files using
find . -type f -mtime -1
The -1 is days back, you can try -2, -3 etc. If this is a recent problem hopefully this will show a recently modified file. It will look a lot like gibberish when you open a file that is bad.
Again unfortunately, if they are smart they will adjust the time on the file to be something a few weeks back or what ever, thus making the file much harder to find.
Did you purchase your WordPress theme yourself and from the original provider? I would download Theme Authenticity Checker and run the plugin -- it finds malicious code within the theme. I know you checked the theme files, but better be safe than sorry. Usually, purchased themes have no problem but downloaded ones often have malicious code such as this.
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.