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.
Related
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
We have a user that has zero width spaces that are ending up at the end of URL's that he is copying and pasting from an outlook email client into his WordPress 4.9.4 site. This doesn't happen on all of the sites, just some of them. The issue is happening just on a standard page using the TinyMCE tools to create the link.
Is anyone aware of a way to easily have WordPress strip these out? I don't know what the "correct" behavior is on these - but it certainly causes for some unique troubleshooting cases for the uneducated.
Another way to state this: Is anyone aware what the "default" behavior is on WordPress TinyMCE with handling "zero width spaces"? I have a user running into issues with them (not sure how they are getting there) and I've never seen this before.
My client is using Tribe Events for, well, managing his events :) I was asked to make a new theme for him. I downloaded his old installation and created new theme, checked and everything was great. I uploaded the whole thing to my server - works as well. But when I finally got the thing on my client's host, every link leading to Tribe Events' content is leading back to main page. Strange thing - it happens only when my theme is on. But then again, I tried removing tribe-events directory from the theme, renaming it etc. Nothing helps. Any ideas?
You didn't provide details about the way you use it so I am not sure the way to provide exact reply.
If you use it without default page template (plugin one) then you should check your loop.
Did you override any files or did you change plugin files at all.
Make sure there is no extra loop running and if you use lops on page make sure you finish it properly
And finally - try to reset permalings, both theme and plugin, if any
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.
We are using the NextGen Gallery plugin to generate a slideshow in a Wordpress site. I needed to change the site URL to a a different subdomain, and this seems to have broken the links. The plugin-generated javascript still passes the old URL to swfobject.embedSWF.
Does anyone know how to fix this? I already updated the Wordpress "General Settings" with the new WordPress address and Site address (which are the same), and the plugin does not seem to pick up that change. Thanks!
Found it. It's in the string-encoded ngg_options entry in the wp_options table. The specific field is "irURL".
Why they chose to capture the site URL independently, instead of reading it from the Wordpress site configuration, is beyond me.
Could it be that NextGen has hardcoded those values somewhere in its database tables?
It could be a matter of running a bunch of SQL update queries to replace any instances of http://old.domain for http://new.domain
And now I'll state the obvious, recommending you to backup the full DB before you attempt any of this.
I had the same problem (unchanged absolute CSS/JS files' paths) after domain changing although I changed every single old domain's occurrence in database (even in serialized arrays/objects in options).
I found solution on http://www.nextgen-gallery.com/galleries-opening-lightbox/ - I didn't have time to do an investigation where they store these paths or in which format. :P
For me it is extremely stupid in Wordpress that it stores absolute paths (with one and the same domain) in so many places but that's another matter. :)