herko

The problem was an infinite loop in the theme.co Pro theme. But I agree with @defmans7 that WP Core shouldn’t auto upgrade to failure. This is something that was introduced in the 6.2 core, as the infinite loop wasn’t triggered in versions prior. So even tho the theme was causing it, the core allowed for it, and that should have been known.

I get the following error in WC:

[Error] SecurityError (DOM Exception 18): Blocked a frame with origin “https://fast.wistia.net” from accessing a frame with origin “https://[mydevsitehere]”. Protocols, domains, and ports must match.

This is an error generated by Ghostery, even though Wistia is whitelisted. Trying to add a new product and using the Characteristics tab to add a custom characteristic to a variable product. This is the only error on the page, and the page hangs now.

reported here: https://core.trac.www.ads-software.com/ticket/39391

Rolled back to 4.6.1 and the site works again. Submitting bug report!

same here. Site is running php 5.3.29 CGI (stable).

<nevermind, fixed it myself. I hadn’t finished all the domain mapping steps >

Any update on this? Some media are focussing their attentions on websites that ignore the cookie directive or its implementations into national law. Having a plugin that complies is a good thing, methinks.

Like I said in my post, I have done the steps in the Moving_Wordpress codex page. I’ve checked all database entries, I’ve checked all the files, I’ve made the changes to wp-config, the thing that bugs me is the error. What is causing it?

So I ask again: what can cause the Fatal error: Call to undefined function get_translations_for_domain() in /path/to/my/domain/wp-includes/l10n.php on line 81.

It seems it’s a problem caused by the Redirection plugin. See iLERTECH’s excellent writeup of the problem and the way to fix it: https://www.ilertech.com/2010/08/whats-wrong-with-the-wordpress-redirection-plugin/.

solution doesn’t work. It needs to be fixed in the WP core, but the trac report isn’t assigned to any specific version, just ‘future version’. So it’s not in line to be fixed yet.

It seems I have a solution to this issue: set the widgets to show on the ‘home page’ (checkbox in the list at the bottom of the page) for those widgets you want to show on the static posts page ou set in your WP settings.

And Happy New Year to you too ??

* milestone changed from 2.9 to Future Release

Agree this bug should be fixed, but since we’re in beta 2 now, punting to next release cycle for further testing and/or revision.

Wow. this is an issue that’s been open for a year, and it gets delayed because ‘we’re in beta 2 now’? I thought putting issues in milestones was meant to ensure they’d be fixed in those milestones, and motivated if and when this would not be the case. This is just bad release management!

I did use this on another site where the blog posts were news bits on a page called News, which isn’t the home page, and it worked fine.

That’s where it fails for me, oddly enough. I have a static page called ‘news and blog’, and set is as my posts page. And I added 2 widgets to show on that ‘news and blog’ page, and on all posts pages, but they do not show up.

My home page is another static page, and I can add widgets to that page only just fine..

I’m using WP 2.8.6.

updated trac report here: https://core.trac.www.ads-software.com/ticket/10332

I started my log afresh, wanting to add content from before 1900 even, hoping that the published date would show up in the URL as well. But I can’t create an archive from before 1969 (and only then because of my server timezone enables a few hours difference from the unix epoch 0).

There seems to be another check for negative dates because I commented out the lines in functions.php, but to no avail.