trejder

UPDATE: Problem has been traced to be caused by Markdown QuickTags plugin, not WordPress itself. Deactivating this plugin and reverting post/page editor back to standard one removes problem and Right Alt + Z shortcut works fine! Sorry for making noise.

Either you’re talking about different plugin (there is very similar one, called Admin in English with Switch) or you messed something up.

I’ve just installed and enabled this plugin for my WordPress Network with 3.5.1 engine version. And it works just fine. All my dashboards are back into English, while blgos remains in other languages.

Glad, I could help! :] All the best…

@boise777: First go to your Network Dashboard > Settings > Domain Mapping Configuration and make sure that you:

a) set your server’s correct IP address,

b) checked first four (out of five) checkboxes bellow (at least this is, what I have checked).

Then go to dashboard of each site of your network, to Tools > Domain Mapping and change Primary Domain from subdomain to your top-level domain.

If I’m not mistaken, if you add new site to your network, by default its domain will be set to subdomain.network.com and you have to manually switch it to your top-level domain.

This solution looks great (though I’ve already entered my Akismet API for each of my network’s site). But it doesn’t change the fact, that bug menioned in this thread should be fixed ASAP! :]

Ah, I think I found it. Thanks! :]

Quite surprising. Can someone from Akismet development team please kindily explain, why Akismet needs these sensitive data to just fight spam in comments?

@all: This case (except for RonStrilaeff’s reply) has been discussed 4 months ago and the link in Network admin is still broken, leading to “Access Violation” error message. Haven’t you fixed this yet / updated Akismet plugin for such long time?

@ronstrilaeff: No way, their going to do this, because this is bad. Most people uses WordPress Network to manage own network of blogs from one general dashboard (with registration of new sites disabled by default). But think about those, who run sites like WordPress.com, which are open for registration of new sites. Admins of such networks for sure require, that end-point users enter own Akismet API key as they don’t want hits from user sites to enlarge hits counter of their own Akismet account. Especially, if they’re enterprises and had to pay for API key and will have to pay extra in pay-per-call mood, once their network overall hits count passes certain limit (of 100k hits per day, if I’m not mistaken). So for such installations having abillity of entering different API Keys per different sites is surely most welcome.

I’m quite new to WordPress, so I don’t know about what setting you’re talking about and where to change it? Can you guide me?

Right now no matter if I use domain.network.com (subdomain URL) or domain.com (mapped domain) I’m always redirected (for login) to domain.network.com/wp-login.php, and after logging-in, your plugin is redirecting me to domain.com, which is why login fails.

I know very well about security issue you’re talking about. I just suggested, that if your plugin is doing redirection domain.network.com –> domain.com, then it should be able to read WordPress login cookie from domain.network.com before redirection, send it to domain.com as POST or sth and then, the same plugin under domain.com could check, if there is any data sent via POST, if so, then dump it to a login cookie for domain.com. But that’s just my theoretical attempt to solve this problem.

WordPress is a blogging platform, not a CMS or shopping system, so don’t expect to find any plugin that will handle payment transactions for you, as there aren’t many WordPress users interested in the same.

However, I would suggest considering stripe.com, which offers all the functionallity, you’re asking for, exported outsite as really simple and easy to use API.

You can then write your own, quite simple plugin that will act like a bridge between your dashboard or whole multisite WordPress installation and stripe.com.

At least I would go that way, if I would be in your situation.

WordPress Multisite installation uses the same authentication mechanism as standard, single WordPress installation. If you don’t find any help / answer here, post your question into general troubleshooting forum, as this question is not specific to Multisite instllation.

Thanks! This does seems to be a good idea.

This problem is probably caused by redirection done by Domain Mapping plugin and the fact that WordPress login cookie (written for original domain) is not available for domain to which Domain Mapping redirects to.

Look into this question or this support issue for more details.

Seems that I had similar problem (here). I wanted domain with www prefix works separately, without redirecting to non-www domain (but of course both should display the same page, only a matter of URLs).

As plugin’s author replied me, this is beyond his plugin, redirection is obligatory, because that is how WordPress Networks works.

Nick,

On both addresses you’ve mentioned, I see two different blogs (I think — I don’t know your language). I’ve tested this (both addresses) in three different browsers (Chrome, IE, FF) and refreshed each page in each browser few times. There is no blank page at all.

Maybe that was just a temporal problem or something had to refresh in your DNS or domain settings? I don’t know. But right now all seems to be working just fine.