View Full Version: vBET 3.3.4 frigivet
Hej:)
Vi har for jer nye udgave af vBET. I denne version har vi forbedret ydeevne (vigtigste - fuld fil cache for gæster) og også nogle nye funktioner og få fejl rettet. God fornøjelse! :)
Nyt:
Performance forbedringer
Tidligere omdirigeringer for vBSEO forkerte URL'er
Fuld fil cache for gæster
Konfigurerbare fil cache tid til at leve
Konfigurerbare fil cache tid til at leve for mindre relevante sider
Konfigurerbare sæt af mindre relevante sider
Konfigurerbare sæt af sider ignoreret ved fuld fil cache for gæster
Alle flag billeder taget som en fil fra server (CSS sprite understøttes)
Ignorerede ord / sætninger funktionalitet
Understøtter: Indlæg, gruppebeskeder, besøgende beskeder, billede kommentarer, private beskeder
Opaque ignorerede ord i allerede eksisterende meddelelser
Understøtter: Indlæg, gruppebeskeder, besøgende beskeder, Billede kommentarer
Mulighed for at ikke oversætte indholdet af kode html-tag
Ændret skabeloner:
vbenterprisetranslator_inpost_translate
vbenterprisetranslator_inpost_translate_alreadyin
vbenterprisetranslator_flag
Fejl rettet:
Defineret DIR for vbseo
Span bryde nogle layouts
Oversæt langtitle når der svares besked
Arkiv med vBSEO 3,5
Lagring af brugerdefinerede felter i profiler i henhold til oversat side
Broken langtitle til lange titler med auto 'Re:' muligheden
langtitle analyseres med hensyn til newreply om oversat udsigt
Multi langtitle uigennemsigtig
Og nogle få ord om nye Full Fil Cache for gæster funktionalitet. Når du tænder for den vil kontrollere, gør anmodning fra brugeren, der ikke er logget ind Hvis det er fra gæst så vil det se de fører ikke allerede er cached. Hvis det er - fuld HTML-svar vil blive taget fra cachen. Hvis ikke så vil det være cachet, når output er genereret. Bemærk venligst, at det vil arbejde også for din originale sider - så det vil forbedre generations tid og gøre mindre DB forespørgsler også for ikke oversatte sider. Det er yderst konfigurerbar. Det betyder at du kan konfigurere ikke kun cache tid, men du kan også definere hvilke sider du confider mindre relevant, og for disse sider kan du indstille længere cache tid. Som standard cache tid til normalsider er 1 time (det betyder, at gæsterne kan se forum ændringer efter 1 time, hvis side var lige cached), og for mindre relevante sider, som standard er det 15 dage. Selvfølgelig er det konfigureres af Admin CP. Også du kan definere, hvilke sider der skal ignoreres af Fuld File Cache for Guest.
Vi testede det for lidt tid på vores forum, vi stadig betragte denne funktionalitet som BETA. Også bemærk venligst, at du bliver nødt til at indstille relevante privilegier til cachemappe at være i stand til at bruge det - ellers cache filer vil ikke blive genereret. Detaljer i konfigurationen beskrivelse.
PS.
Vi vil inkludere det også i vBET 4.x snart:)
I dont forstå denne fil cache, hvorfor skulle du brug for en 2. cache, hvoraf den vigtigste i forvejen cacher sider og kun opdateringer, når der tilføjes nyt indhold, så hvorfor cache det i 1 time igen, din forklaring er vanskelig at forstå.
Super Mate!
Takket være en million,
Darn: Troede det var for 4.0.x. .. Cool enten måde selv ... Kan ikke vente til 4.0.x version. :)
bhanuprasad1981
21-06-10, 18:51
venter på 4.x version:)
Hvordan redigerer jeg css for flag venligst, nødt til at ændre, hvordan de viser, som det ser underligt som det er.
Er kundesupport øjeblikket er til rådighed? Denne seneste opdatering er årsag omdirigere loops, og jeg har brug for assistent hurtigst muligt.
venter på 4.x version:)
Hej,
Jeg vil også vente til 4.x udgave ;-)
wowglider.de
22-06-10, 00:05
Ingen monteringsvejledning (eller opgraderingsinstruktionerne)?
Ya hvorfor er vi opdaterer vb 3 ting, når dens vb4. nu.
Come on vbet vi burde få vbet opgraderet til vb 4 først!
Ya hvorfor er vi opdaterer vb 3 ting, når dens vb4. nu.
Come on vbet vi burde få vbet opgraderet til vb 4 først!
Hvorfor tror du, du er noget bedre som vb3 brugere?
Opgraderes efter server belastning problem: (
Er der nogen der har nogen idé om, hvor stor den fil cachen kunne få, før det har en negativ indvirkning på ydelsen?
I dont forstå denne fil cache, hvorfor skulle du brug for en 2. cache, hvoraf den vigtigste i forvejen cacher sider og kun opdateringer, når der tilføjes nyt indhold, så hvorfor cache det i 1 time igen, din forklaring er vanskelig at forstå.
Database cache caches kun oversættelser. Ikke hele HTML-indhold. Så når nogle oversat side er genereret, så første normale side er genereret, og efter at det analyseres, og oversættes. Under oversættelsen DB cache bruges og oversat sætninger er taget derfra. Bare sætninger - ikke hele HTML, fordi hver gang oversættelser kan være forskellige (dvs. forskellige privilegier af brugere, ændret indhold). Et HTML-side kan have hundredvis af sætninger at oversætte - vBET tager indhold mellem HTML-tags. Takket DB cache disse oversættelser behøver ikke at blive taget hver gang fra Google - hvad bruger masser af tid - i stedet for det, er dem, taget fra din lokale DB. Stadig - normal side skal fremskaffes og derefter oversat.
Fuld Fil Cache For gæster virker kun for gæster. Takket være, at vi ikke behøver at bekymre dig, at brugerne har forskellige privilegier og se forskellige ting. ll gæster se det samme indhold. På grund af at vi ikke behøver at parse resultatet og oversætte det stykke for stykke, hver gang - vi kan bare gøre det en et stykke tid og cache fuld HTML-output. Så i dette tilfælde, når hele siden ikke er cachet, eller cached indhold er for gammel, så normal oversættelse sker - ligesom beskrevet før. Men denne gang til allersidst fuld HTML-output er skrevet til filen. Så næste gang, når samme opfordring kommer fra gæster, vi ikke generere endnu normal sidens indhold - vi simpelthen streame til gæst allerede cachede HTML-fil. Det er derfor, vi sparer masser af SQL-forespørgsler, CPU og hukommelse. Vi skal bare give brugeren indhold fra statisk fil. Derfor er det vigtigt at afgøre, hvor længe denne cache vil være gyldig. For hvis noget vil ændre sig - dvs nyt indlæg ankommer til tråden, så gæsterne vil ikke se denne nye post, indtil der allerede cached fil udløber. Efter at der i løbet næste anmodning vil igen normal siden blive genereret, oversat, og cached - og dette indhold gæster vil se dvs. for anden time (konfigurerbar). De vil ikke se nogen ændringer, før cachede filen udløber igen. Selvfølgelig dine brugere vil se alt, fordi det virker kun for gæster (så for robotter også, fordi robotter gennemgår dit forum som gæster).
Fortæl hjalp det og i tilfælde af eventuelle spørgsmål bare spørg - vi vil gerne beskrive det mere:)
Super Mate!
Takket være en million,
Darn: Troede det var for 4.0.x. .. Cool enten måde selv ... Kan ikke vente til 4.0.x version. :)
Det vil være, vil det være:) De fleste nye ting er allerede testet der. Vi skal bare have mere at gøre i tilfælde af en fuld Fil Cache for gæster på vB4, fordi vi støtter der oversættelse af flere former for webadresser for vBSEO og også venligt webadresser fra VB. Og af alle dem, vi er nødt til at teste det meget nøje og har stadig til at gennemføre støtte af tidligere omdirigere for nogle af dem. Også - Vi vil bruge denne ekstra tid til at kontrollere eventuelle problemer med Full Fil Cache For gæster (som anses BETA nu) på vB3 fora. Vi tester det godt, men det er altid bedre at tage sig mere om god kvalitet:)
Hvordan redigerer jeg css for flag venligst, nødt til at ændre, hvordan de viser, som det ser underligt som det er.
i filen / images / vbet / flag / vbet.css
Beskriv bedre, hvad det betyder "underlig" - måske vil vi i stand til at hjælpe dig. Ligeledes anbefaler vi at bruge til sådanne ting Firefox med plugin Firebug - det vil give til at vise dig præcis hvilke css styles der anvendes til nærmere bestemte elementer. Det er virkelig nyttigt:)
Er kundesupport øjeblikket er til rådighed? Denne seneste opdatering er årsag omdirigere loops, og jeg har brug for assistent hurtigst muligt.
Vi fik din e-mail og tjekke det. Vi kan ikke reproducere det på din server. Du fik svar med spørgsmålet om, nøjagtig URL adresse, som har denne løkke. Forhør dig det, og svar der:)
Ingen monteringsvejledning (eller opgraderingsinstruktionerne)?
Standard. Bare sørg for at gøre det hele. Mest brugere ønsker ikke at uploade billeder igen - du skal i denne version. Nu har vi et billede for alle flag. Hvis du ikke foretaget fuld opdatering, vil du se brudt flag.
Ya hvorfor er vi opdaterer vb 3 ting, når dens vb4. nu.
Come on vbet vi burde få vbet opgraderet til vb 4 først!
Jeg ved, at for alle hans version er vigtigst;) Og vi ønsker ikke at argumentere imod den:) I dette tilfælde vBET3.x er tidligere for meget god grund: KVALITET. Vi tilføjer nye vigtige funktioner (Full Fil Cache for gæster) i denne version, og det var meget lettere at tilføje det i vB3, fordi der ikke er nogen venlige URL'er, og vi oversætter kun tråd webadresser for vBSEO. I tilfælde af vB4 det er mere kompliceret - venligt URL'er skal støttes, og vi oversætter meget mere typer af URL'er. Sætte det første i vB3. gav os mulighed for at teste det meget godt på reelle fora, at det fungerer fint check, vil måske vise nogle bugs, før det går til vB4. Og efter vi er completly sikker på at det er alt fint, vi stadig nødt til at tilføje i vB4 aditional støtte (Friuendly webadresser, mere translted URL'er). Derfor er denne tid vBET3.x er tidligere og vi har stadig brug for 2 uger for vBET4.x. Og takket være, at du vil få løsning, som har meget god kvalitet, Ewen hvis det er mere kompliceret thatin tilfælde af vB3
Opgraderes efter server belastning problem: (
Vær åbne nye tråd i afsnittet Fejlfinding og beskrive det mere.
Er der nogen der har nogen idé om, hvor stor den fil cachen kunne få, før det har en negativ indvirkning på ydelsen?
Der må ikke være sådan noget som en negativ indflydelse på ydeevnen på grund af fil cache. Det er fordi Fil cache ikke vokser ... Vi skaber separat fil for hver anmodning webadresse. Så hver cache-fil er blot statisk HTML-fil (cached udgang til anmodning). Når din server cacher mere og mere vBET blot skaber flere og flere filer. Så hver gang, når en sådan fil er læst:
1. Det er kun læsbar resultat for denne webadresse
2. Vi har endda ikke læse det til hukommelsen - simpelthen streame det til klienten ved hjælp af PHP funktion: readfile
På grund af, at selv hvis dit resultat side er meget stor - så cache-fil er også store, vil det have nogen negativ indflydelse på ydeevnen, fordi det bare vil streame denne ene fil, endda uden at læse hele den i hukommelsen. Så vil du se fordele ikke ulemper.
Tak for forklaringen, jeg nu forstår, jeg ling flagene se bundter sammen, så jeg fordelt dem ud med nogle brugerdefinerede css margen.
En sidste ting, din nye kode ikke validere W3.
[Ugyldig] Markup Validering af http://www.computer-juice.com/forums/f43/pc-overclocking-guide-4465/ - W3C Markup Validator
Også en anden fejl, når jeg aktiverer vbet, på nogle sider tråd værktøjer pauser, dvs linket øverst - drop down menu pauser. Så tråden værktøjerne i bunden af tråden mangler er det ikoner. Også 'Besvar' ikonet forsvinder. Dette fejlrettelser sig selv, hvis jeg deaktiverer vbet. og det kun sker for gæsterne. Thanks.
Se her - Eternal "Erhvervelse af netværksadresse" på netkortet - Computer Juice
Tak for forklaringen, jeg nu forstår, jeg ling flagene se bundter sammen, så jeg fordelt dem ud med nogle brugerdefinerede css margen.
En sidste ting, din nye kode ikke validere W3.
[Ugyldig] Markup Validering af http://www.computer-juice.com/forums/f43/pc-overclocking-guide-4465/ - W3C Markup Validator
Ja - du har ret. Vi vil flytte vores css link til andet sted. Tak for note:)
Også en anden fejl, når jeg aktiverer vbet, på nogle sider tråd værktøjer pauser, dvs linket øverst - drop down menu pauser. Så tråden værktøjerne i bunden af tråden mangler er det ikoner. Også 'Besvar' ikonet forsvinder. Dette fejlrettelser sig selv, hvis jeg deaktiverer vbet. og det kun sker for gæsterne. Thanks.
Se her - Eternal "Erhvervelse af netværksadresse" på netkortet - Computer Juice
Skal du åbne ny tråd for dette i Bugs Rapportering afsnit:) Vi vil være i stand til at forvalte det. Også når du vil skrive det her, kan du bekræfte betyder det sker med Full Fil Cache til gæsternes tændt, eller det gør ikke noget.
Vi fik din e-mail og tjekke det. Vi kan ikke reproducere det på din server. Du fik svar med spørgsmålet om, nøjagtig URL adresse, som har denne løkke. Forhør dig det, og svar der:)
Hej
Jeg opdaterede vbseo fra version 3.3.0 til 3.5.1, og problemet gik væk:)
tak
Der må ikke være sådan noget som en negativ indflydelse på ydeevnen på grund af fil cache. Det er fordi Fil cache ikke vokser ... Vi skaber separat fil for hver anmodning webadresse. Så hver cache-fil er blot statisk HTML-fil (cached udgang til anmodning). Når din server cacher mere og mere vBET blot skaber flere og flere filer.
Fremragende, det cachemappe på en af vores forum er over 10GB efter at have kørt i ca 12 timer, performance er fantastisk, det er en god løsning.
Jeg har hårdt brug for hjælp. Efter opgraderingen har jeg denne fejl på toppen af mit forum:
Advarsel: array_merge () [function.array-merge]: Argument # 1 er ikke et array i [sti] / global.php (400): eval () 'd code on line 1153
Hele min forum er helt rodet op. Af en eller anden grund dette kun sker, hvis ikke logget ind Så for gæster. Hvis der er logget ind, alt er fint.
EDIT: OK, jeg indså, at efter at jeg har deaktiveret Brug 'Fuld Fil Cache For gæster (BETA!)' alt er i orden. Så der må være noget galt der. (Og jeg gjorde CHMOD 777-R vbet_guestcache)
Jeg har hårdt brug for hjælp. Efter opgraderingen har jeg denne fejl på toppen af mit forum:
Advarsel: array_merge () [function.array-merge]: Argument # 1 er ikke et array i [sti] / global.php (400): eval () 'd code on line 1153
Hele min forum er helt rodet op. Af en eller anden grund dette kun sker, hvis ikke logget ind Så for gæster. Hvis der er logget ind, alt er fint.
Hvad er din webadresse?
EDIT: OK, jeg indså, at efter at jeg har deaktiveret Brug 'Fuld Fil Cache For gæster (BETA!)' alt er i orden. Så der må være noget galt der. (Og jeg gjorde CHMOD 777-R vbet_guestcache)
Ok, jeg havde brug for at undertrykke PHP fejl, blev cachen kontrol af filen alder på filer, som ikke eksisterede og var aflytning ud. Filen cache er en awesome Desuden, hvis du kan bruge det du plejer fortryde det.
Ja, jeg klar over dette. Jeg håber virkelig, at Michael kan sortere dette.
Ja, jeg klar over dette. Jeg håber virkelig, at Michael kan sortere dette.
Ingen probs. Jeg var bare foreslå det, fordi når jeg løber ind i et lignende problem i går, blev jeg mødt med tavshed her. Jeg gætter på community-medlemmer at hjælpe hinanden? Jeg personligt ville ikke forsøge en større opgradering, hvis jeg vidste, at støtte ikke ville være til rådighed for de næste 6 eller 8 timer eller mere.
Thanks Steve mand! Jeg virkelig sætter pris på det!
Jeg har hårdt brug for hjælp. Efter opgraderingen har jeg denne fejl på toppen af mit forum:
Advarsel: array_merge () [function.array-merge]: Argument # 1 er ikke et array i [sti] / global.php (400): eval () 'd code on line 1153
Hele min forum er helt rodet op. Af en eller anden grund dette kun sker, hvis ikke logget ind Så for gæster. Hvis der er logget ind, alt er fint.
EDIT: OK, jeg indså, at efter at jeg har deaktiveret Brug 'Fuld Fil Cache For gæster (BETA!)' alt er i orden. Så der må være noget galt der. (Og jeg gjorde CHMOD 777-R vbet_guestcache)
Skal du åbne ny tråd for dette i fejlrapporter. Vi vil være i stand til at håndtere denne her.
Ok, jeg havde brug for at undertrykke PHP fejl, blev cachen kontrol af filen alder på filer, som ikke eksisterede og var aflytning ud. Filen cache er en awesome Desuden, hvis du kan bruge det du plejer fortryde det.
Dette er i formålet - at vi ikke kontrollerer ikke filen findes, for at undgå unødvendige IO operationer. Ifølge PHP manualen (PHP: filemtime - Manual (http://php.net/manual/en/function.filemtime.php)) Funktionen filemtime returnerer false for ikke eksisterende filer. Vi var ikke klar over om nogen fejlmeddelelser - ifølge manualen denne funktion bør ikke sende nogen fejl i tilfælde af ikke eksisterende fil. Kan du venligst åbne nye tråd i Troubleshoting og fejlrapporter til at med eksempel på din fejlmeddelelser?
Til alle - skal du ikke behandle denne tråd, som eneste sted om denne vBET version. For problemer eller bugs - så skriv i passende sektioner. Vi vil ikke være i stand til at håndtere dine spørgsmål, hvis de vil være her.
haiduongbk
24-06-10, 09:27
Jeg har opgraderet fra 3.3.4 op i 2 dage. På første link på google Indsendt ikke så meget som hver dag, og i dag så falder. Jeg forstår ikke, hvorfor trods af alle indlæg emner og stadig vokser normalt. Hvem er ligesom mig? Jeg faldet fra 145.000 til 139.000 links på Google
Jeg har opgraderet fra 3.3.4 op i 2 dage. På første link på google Indsendt ikke så meget som hver dag, og i dag så falder. Jeg forstår ikke, hvorfor trods af alle indlæg emner og stadig vokser normalt. Hvem er ligesom mig? Jeg faldet fra 145.000 til 139.000 links på Google
Dette har intet at gøre med opdatering til vBET3.3.4 - Google simpelthen ikke reagerer hat hurtigt. Der kan være mange årsager, men det er ikke vBET:)
Eneste grund til at det kunne gøres ved vBET (men ikke på så kort tid) er, hvis nogle oversatte sider ikke ville generere. Hvis du opdager, at nogle sider ikke er kontakt - bemærk det til os. Du kan finde den i webmasterværktøjer.
haiduongbk
24-06-10, 09:52
Tak Michal. Jeg vil følge det mere tid. og lære årsagen.
Tak Michal. Jeg vil følge det mere tid. og lære årsagen.
Mest almindelige er, at folk har glemt, at de foretagne ændringer i robots.txt 2-3 måneder tidligere (ja Google reagerer i en sådan tid - det kan være hurtigere, hvis du har super høj Page Rank). Også nogle gange folk ser på resultater i Google-søgning - hvor er vises kun tilnærmet antallet af indekserede sider, ikke den rigtige. Så tilnærmelse kunne skifte til en bedre en og det betyder ikke, at nogen af dine sider blev fjernet fra indekset. Også - Google er enorm og har masser af databaser, som fra tid til anden opdateres, replikeret og så videre - dette kan kun være effekt af at arbejde Googles database algoritmer. Også Google er ved at ændre det indekserings algoritmer og IE er det muligt, at nogle af dine allerede indekserede sider nu betragtes som en gentagelse af indholdet (dvs. de fleste medlemsstater sider er i 99% samme) og fjernet fra indekser.
Så længe du ikke kan se stort antal fejl i jeres webmaster værktøjer, du kan antage, at det er netop, hvordan Google fungerer. Men hvis du ser fejl - så er det på din side, og så skal du reagere.
Der må ikke være sådan noget som en negativ indflydelse på ydeevnen på grund af fil cache. Det er fordi Fil cache ikke vokser ... Vi skaber separat fil for hver anmodning webadresse. Så hver cache-fil er blot statisk HTML-fil (cached udgang til anmodning). Når din server cacher mere og mere vBET blot skaber flere og flere filer. Så hver gang, når en sådan fil er læst:
1. Det er kun læsbar resultat for denne webadresse
2. Vi har endda ikke læse det til hukommelsen - simpelthen streame det til klienten ved hjælp af PHP funktion: readfile
På grund af, at selv hvis dit resultat side er meget stor - så cache-fil er også store, vil det have nogen negativ indflydelse på ydeevnen, fordi det bare vil streame denne ene fil, endda uden at læse hele den i hukommelsen. Så vil du se fordele ikke ulemper.
Hrmm, jeg kan lide tanken om at caching oversat data, men ville det ikke være mere effektiv, hvis den bruges noget memcache? I stedet for at læse data fra disken ville læse den fra hukommelsen.
Hrmm, jeg kan lide tanken om at caching oversat data, men ville det ikke være mere effektiv, hvis den bruges noget memcache? I stedet for at læse data fra disken ville læse den fra hukommelsen.
Støtte af eksisterende cache biblioteker er på ud TODO liste. Desuden findes alle fil cache for gæster være virkelig store for store fora. For store til at holde det helt i hukommelsen - vi vil lede efter løsninger, som gør det muligt at kombinere fordelene ved at holde cache i hukommelsen og på disken.
haiduongbk
02-07-10, 01:29
Mest almindelige er, at folk har glemt, at de foretagne ændringer i robots.txt 2-3 måneder tidligere (ja Google reagerer i en sådan tid - det kan være hurtigere, hvis du har super høj Page Rank). Også nogle gange folk ser på resultater i Google-søgning - hvor er vises kun tilnærmet antallet af indekserede sider, ikke den rigtige. Så tilnærmelse kunne skifte til en bedre en og det betyder ikke, at nogen af dine sider blev fjernet fra indekset. Også - Google er enorm og har masser af databaser, som fra tid til anden opdateres, replikeret og så videre - dette kan kun være effekt af at arbejde Googles database algoritmer. Også Google er ved at ændre det indekserings algoritmer og IE er det muligt, at nogle af dine allerede indekserede sider nu betragtes som en gentagelse af indholdet (dvs. de fleste medlemsstater sider er i 99% samme) og fjernet fra indekser.
Så længe du ikke kan se stort antal fejl i jeres webmaster værktøjer, du kan antage, at det er netop, hvordan Google fungerer. Men hvis du ser fejl - så er det på din side, og så skal du reagere.
Har en uge går af numrene på min hjemmeside på google forbliver stort set uændret og kan selv gå op og ned meget små men kunne ikke komme igennem 145000 figur (figur af den foregående uge). 2 dage siden det holdt 145000. Og i dag er 143000. Jeg ikke konfigurere eller ændre noget om robots.txt-filen fra sidste 6 måneder nu. og jeg konfigureret robots.txt fil er som følger: brugeragent: Mediapartners-Google * Disallow: opdateret status rapport stadig sitemap indeks er vellykket, men webadresserne indsendt øger jo længere webadresser i Webindeks er fundet beliggende på falder. Jeg ved ikke, hvad der skete med mig igen, kan du hjælpe mig hvordan? Jeg ved ikke, hvor at forårsage. Jeg bruger VBET kapitel 2.10 ca. 1 måned, men på tidspunktet jeg ikke konfigurere vBSEO Sitemap Generator som anvist af dig her (http://www.vbenterprisetranslator.com/forum/vbet4-integration-other-plugins/415-sitemap-generator-integration.html)) men da skiftede til en kommerciel 3.3.3 jeg var interesseret og læse instruktionerne for at konfigurere config fil til sitemap. I første omgang med en meget fin se jeg 3.3.3 begejstret over stigningen i Google-indekset. Da opgraderingen til 3.3.4, derefter få. Jeg ved ikke, hvorfor mere? Ser frem til din hjælp. kun 19 fejl tid ud i rapporten fra mit websted i Google Webmaster tools
Har en uge går af numrene på min hjemmeside på google forbliver stort set uændret og kan selv gå op og ned meget små men kunne ikke komme igennem 145000 figur (figur af den foregående uge). 2 dage siden det holdt 145000. Og i dag er 143000. Jeg ikke konfigurere eller ændre noget om robots.txt-filen fra sidste 6 måneder nu. og jeg konfigureret robots.txt fil er som følger: brugeragent: Mediapartners-Google * Disallow: opdateret status rapport stadig sitemap indeks er vellykket, men webadresserne indsendt øger jo længere webadresser i Webindeks er fundet beliggende på falder. Jeg ved ikke, hvad der skete med mig igen, kan du hjælpe mig hvordan? Jeg ved ikke, hvor at forårsage. Jeg bruger VBET kapitel 2.10 ca. 1 måned, men på tidspunktet jeg ikke konfigurere vBSEO Sitemap Generator som anvist af dig her (http://www.vbenterprisetranslator.com/forum/vbet4-integration-other-plugins/415-sitemap-generator-integration.html)) men da skiftede til en kommerciel 3.3.3 jeg var interesseret og læse instruktionerne for at konfigurere config fil til sitemap. I første omgang med en meget fin se jeg 3.3.3 begejstret over stigningen i Google-indekset. Da opgraderingen til 3.3.4, derefter få. Jeg ved ikke, hvorfor mere? Ser frem til din hjælp. kun 19 fejl tid ud i rapporten fra mit websted i Google Webmaster tools
Efter min mening nok ikke sker noget. Du har ingen fejl i Webmasterværktøjer. 143 000 eller 145 000 - det ligner skøn ikke er reelle, nøjagtige antal af indekserede sider. Og hvis det er skønnet så skønnes resultater kan variere. Hvorfra man tager disse tal?
Også en anden fejl, når jeg aktiverer vbet, på nogle sider tråd værktøjer pauser, dvs linket øverst - drop down menu pauser. Så tråden værktøjerne i bunden af tråden mangler er det ikoner. Også 'Besvar' ikonet forsvinder. Dette fejlrettelser sig selv, hvis jeg deaktiverer vbet. og det kun sker for gæsterne. Thanks.
Se her - Eternal "Erhvervelse af netværksadresse" på netkortet - Computer Juice
Rettes, og vil blive medtaget i vBET 3.3.5:)
Automatic Translations (Powered by Google, Microsoft®,
Yandex, SDL Language Cloud, IBM Watson and Apertium):
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.
