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
Related
I'm working with WP on different subdomains, and for some reason a link on the landing page isn't going to the subdomain, but rather it's trying to go to a page that doesn't exist on the main domain level. I'm guessing this is some kind of auto direct issue, but the link is correct and I'm not sure what is causing this.
The main domain is in staging status: staging2.definingstudios.com. There are three links there, Lifestyle, Schools, and Commercial. The linnk to schools had been doing this too, but then it stopped and is working properly, but the Lifestyle one is trying to go elsewhere.
Thoughts?
Thanks,
Christine
This isn't a WP issue but generally an issue with the theme. They tend to save this data in the DB. A lot of the time its serialized and doesn't get updated.
You can do a few things. Search the DB and see if you can find it. Use a plugin to do it or 95% of the time just go into that page and update/save and it generally fixes it.
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
I have migrated website to new domain, the problem is css not loading
if I inspect element it gives link to old domain, is there a way to update css links in wordpress?
please help
When moving a WordPress site to a new domain, you need to change the Site URL and Home URL, usually in the database or in wp-config.php, depending on how the site was originally set up. There may be other changes you need to make in the database, or by manually editing posts, like the locations of images in posts.
This page on wordpress.org is a good reference, for all the things you may need to change, and it shows a few different methods to make most of the changes, so you can choose the one you prefer:
https://codex.wordpress.org/Changing_The_Site_URL
Make sure to keep a backup of the site in case of any mistakes. If you make some changes, and most of the site is working, but a few things aren't, I would recommend making another backup, so you could restore it again without losing much work, if needed.
yes when you are adding links to your site you show use the function site_url().example/my_post in order to construct the links
I'm using "Formidable Pro" which is a fairly popular plugin like Gravity forms. It has a portion to create forms and take those created entries and display them as "custom displays" which is working great EXCEPT for the fact that I have to go back to the page where the shortcode has been inserted to display these entries and hit update before it will pull the latest entries.
What in the world could be causing this?
I've already tried asking on their support forums and I'm getting no response so I'm kind of desperate. I've made sure that it is NOT the theme or other plugins causing the issue.
Issue lives on this page http://thenextarpg.com/skill-list/
Here where i have to hit update http://imgur.com/8UAque4
Any help would be much appreciated!
The issue is probably your caching plugin. Try disabling WP Super Cache and see if your problem goes away.
Assuming that is what's going on there may be some heavier development required to fix it.
I'd start by looking for a way to tell WP Super Cache never to cache that page.
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.