Disable but not install

[moman]

Due to issues with translation providers, I want to disable vbet for an extended period but still want the option of re-enabling the system to be available.

In addition to disabling the plugin, what changes should I make to vbseo's config and .htaccess in order to make this happen?

Currently, even with the plguin disabled.

If you could provide me with the exact code snippets I would be grateful, as I've deleted my original zip.

[vBET]

Do disable vBET:
1. Disable it in Admin CP
2. Comment vBET rules in .htaccess. If you do not remember which are those then check in vBET package in do-not-upload/tools/redirecting-rules directory
3. Revert integration changes in vbseo files. Easiest way - just upload original files. If you do not have the zip - download it from provider page. Hardest way - just open readme.html in vBET package and there you have exactly described which changes was made - just do it in opposite way.

It is wise to not remove - when removed you will loose whole your database cache.

Please note that today we will release new vBET version which is prepared for translation providers limits. It means that in case if one provider is not available it will switch to another and check previous once per our to see is it available again. Also in case when you already reach your limits in all providers it will use dummy translator - cached translations will be displayed, but for new one you will just see original test instead of empty one like until now. Details will be in announcements. We will release in about 1 hour.

Please tell do you need more help here :)

[moman]

Please note that today we will release new vBET version which is prepared for translation providers limits. It means that in case if one provider is not available it will switch to another and check previous once per our to see is it available again. Also in case when you already reach your limits in all providers it will use dummy translator - cached translations will be displayed, but for new one you will just see original test instead of empty one like until now. Details will be in announcements. We will release in about 1 hour.

I actually implemented these features back when I discovered microsoft's translator. However, their limit is 400,000 chars/hours, or 2,000,000 chars per day (even with OAuth). In the past I was caching over 1GB of translations per day, which would equate to billions of characters, give or take. This means that I would always exceed the providers' quotas during each hour, as I was getting over 2,000 hourly translated pageviews.

This is a real shame as I really liked vbet, my users found it useful, and I had a lot of fun extending and improving it (i.e. ReviewPost integration, etc).

Here is the function I wrote to fetch an OAuth token (which I then stored in memcache until it expired), this would be another suggestion for a future release as microsoft will soon be requiring it:


function request_new_token() {
$obj_connection = curl_init();
$arr_query_bits = array (
'client_id' => 'your client id',
'client_secret' => 'your secret',
'scope' => 'http://api.microsofttranslator.com',
'grant_type' => 'client_credentials'
);
$str_query = http_build_query($arr_query_bits);

curl_setopt($obj_connection, CURLOPT_URL, 'https://datamarket.accesscontrol.windows.net/v2/OAuth2-13');
curl_setopt($obj_connection, CURLOPT_HEADER, 0);
curl_setopt($obj_connection, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($obj_connection, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($obj_connection, CURLOPT_POSTFIELDS, $str_query);
curl_setopt($obj_connection, CURLOPT_POST, TRUE);
curl_setopt($obj_connection, CURLOPT_TIMEOUT, 1);

$str_response = curl_exec($obj_connection);
curl_close($obj_connection);

$matches = array();
preg_match('/\"access_token\":\"([^"]+)\"/', $str_response, $matches);
$token = $matches[1];
preg_match('/\"expires_in\":\"([\d]+)\"/', $str_response, $matches);
$expires = $matches[1];

return array($token, $expires);
}

Another interesting issue in my case is that with vbet off, it seems that google is much more happy to index our site:

http://img543.imageshack.us/img543/6703/statsp.gif

Seems like our loss in traffic won't be that big after all- at least that's good news!

[vBET]

Thanks for your notes.

As I understand your code will be required by Microsoft paid version - is it right?

About the charts - please note that it doesn't tell how many pages was indexed - just how many pages was crawled. And more pages was crawled, because those where delivered faster (see last chart). So Google doesn't react on vBET - it reacts on response time just to not overload your server. When server responses faster robots crawls faster.
I see your sewer started responding faster long time before you disabled vBET (at the beginning of September) - number of crawled started to increase exactly then. So as you see it is related to response time.
I'm interested here about just one thing. You wrote yesterday that you want to disable vBET. So yesterday vBET was still active on your forum, but on charts you marked last 6 days as vBET disabled (as I understand each angle on chart is measurement from one day) - so something it not right here...

According to information got from you Google was crawling (not indexing - it is not the same) much faster when vBET was still active. Only last measurement on charts is when vBET was disabled. Please to not give misleading information. Of course there is connection between response time and number of crawled pages, but your server was answering much faster when vBET was still on. Maybe because instead of waiting for external translation your server immediately got quota exceeded information (it started about week ago). Maybe because of configuration changes (Guest cache turned on month ago or something like that).

And one more think - do you really think that robots traffic has same value as real people traffic? Robots will not click in advertisements, robots will not create account on your forum and robots will not create valuable content on your forum. So personally I think that information that you will have more crawlers traffic is not a good news - it is just news. You will loose real traffic and real people from your community.

Getting back to the issue - do you need more help in this topic?

[moman]

Problem is solved- so nope, don't need more help right now. I would keep the translations around, but due to the high traffic, it's not possible in my case. Maybe in the future a free and powerful API will be made available- who knows!

The issue was that many translated pages were hanging. Adding this to the curl calls did seem to increase overall throughput (my philosophy is that if it doesn't complete in a second, it's not going to complete):
curl_setopt($obj_connection, CURLOPT_TIMEOUT, 1);

This is why the blue area was faster (together with a bigger cache).

While it's certainly open to interpretation, thorough search engine indexing is key to a site's success, and who knows- perhaps the presence of translations was hurting indexing of my site's core (English) content?

[vBET]

We also hope that translations will be free again, we will find more translation providers (free or competitive) or at least it will be cheap :) You can trust us that we want it ;) OK - if no support required now we close this thread. Please keep in mind that we already support providers queue which allows to use one provider as long as you have quote limits ant then automatically switch to another one (and check every 10 minutes does preferred one is available again). Still some issues here (BETA version) - now we mark provider as unavailable if any error happens (it appears not necessary), but we already monitor when providers are marked unavailable on our forum and correct the issues. Hope we will meet again :)