-
Fototrend
Új hozzászólás Aktív témák
-
dqdb
Topikgazda
Végre O16-ban ki lehet takarítani a szemetet a gyorshívóról, a teendők a következők:
1. az opera://flags címen engedélyezni kell az Extensions on opera:// URLs beállítást
2. érdemes a beállításoknál a Preload Discover contents beállítást kikapcsolni, úgysem fog látszódni
3. újra kell indítani az Operát
4. telepíteni kell ezt a kiegészítőt (forrás itt)Az elrejtett tartalom néha egy rövid időre bevillan, ez ellen próbáltam tenni, de sajnos nem sikerült.
Egy rövid ideig elgondolkoztam a kiegészítő nevén, aztán beugrott, hogy volt gyerekszobám, így lett szimplán csak simplifier
![;]](//cdn.rios.hu/dl/s/v1.gif)
Penge_4: a billentyűzetesdi valószínűleg a chrome.commands.* API implementálásának esett áldozatul. Most valami félkész megoldás élhet, mert az API még nem elérhető (figyelmeztetést ír ki egy ilyen bővítmény betöltésekor, hogy ez csak a következő Dev buildben lesz elérhető), de az O15 átdefiniálós megoldása már nem él.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Predator2
addikt
Nah srácok látjátok a fényt az alagút [ O ] végén? Vagy még mindig mozilla lesz az ügy vége?!
fejlesztésekre gondolok[ Szerkesztve ]
>> Ha érdekel valami, vagy nem tudok valamit, akkor Kérdezek << >>McLaren Forever.<< >> Az első és legfontosabb a megbízhatóság, minden más csak sokadik tényező!<<
-
Penge_4
veterán
0x006459e0: int $3
Modules:
Module Address Debug info Name (134 modules)
PE 400000- 2b68000 Export opera
PE 4ad00000-4b682000 Deferred icudt
ELF 7ac00000-7ac60000 Deferred riched20<elf>
\-PE 7ac10000-7ac60000 \ riched20
ELF 7b800000-7ba5b000 Deferred kernel32<elf>
\-PE 7b810000-7ba5b000 \ kernel32
ELF 7bc00000-7bcd9000 Dwarf ntdll<elf>
\-PE 7bc10000-7bcd9000 \ ntdll
ELF 7bf00000-7bf04000 Deferred <wine-loader>
ELF 7d447000-7d44c000 Deferred libgpg-error.so.0
ELF 7d44c000-7d463000 Deferred libresolv.so.2
ELF 7d463000-7d4ad000 Deferred libdbus-1.so.3
ELF 7d4ad000-7d4c1000 Deferred libp11-kit.so.0
ELF 7d4c1000-7d4d3000 Deferred libtasn1.so.3
ELF 7d4d3000-7d557000 Deferred libgcrypt.so.11
ELF 7d557000-7d560000 Deferred libkrb5support.so.0
ELF 7d560000-7d588000 Deferred libk5crypto.so.3
ELF 7d588000-7d656000 Deferred libkrb5.so.3
ELF 7d656000-7d668000 Deferred libavahi-client.so.3
ELF 7d668000-7d72d000 Deferred libgnutls.so.26
ELF 7d72d000-7d76a000 Deferred libgssapi_krb5.so.2
ELF 7d76a000-7d7c9000 Deferred libcups.so.2
ELF 7d7d3000-7d7e6000 Deferred gnome-keyring-pkcs11.so
ELF 7d7e6000-7d81c000 Deferred uxtheme<elf>
\-PE 7d7f0000-7d81c000 \ uxtheme
ELF 7d81c000-7d823000 Deferred libxfixes.so.3
ELF 7d823000-7d82e000 Deferred libxcursor.so.1
ELF 7d82e000-7d83e000 Deferred libxi.so.6
ELF 7d83e000-7d842000 Deferred libxcomposite.so.1
ELF 7d842000-7d84d000 Deferred libxrandr.so.2
ELF 7d84d000-7d857000 Deferred libxrender.so.1
ELF 7d857000-7d85d000 Deferred libxxf86vm.so.1
ELF 7d85d000-7d861000 Deferred libxinerama.so.1
ELF 7d861000-7d868000 Deferred libxdmcp.so.6
ELF 7d868000-7d86c000 Deferred libxau.so.6
ELF 7d86c000-7d88e000 Deferred libxcb.so.1
ELF 7d88e000-7d894000 Deferred libuuid.so.1
ELF 7d894000-7d8ae000 Deferred libice.so.6
ELF 7d8ae000-7d9e5000 Deferred libx11.so.6
ELF 7d9e5000-7d9f7000 Deferred libxext.so.6
ELF 7d9f7000-7da00000 Deferred libsm.so.6
ELF 7da04000-7da08000 Deferred libkeyutils.so.1
ELF 7da08000-7da0d000 Deferred libcom_err.so.2
ELF 7da0d000-7da1b000 Deferred libavahi-common.so.3
ELF 7da1d000-7daaf000 Deferred winex11<elf>
\-PE 7da30000-7daaf000 \ winex11
ELF 7daff000-7db27000 Deferred libexpat.so.1
ELF 7db27000-7db60000 Deferred libfontconfig.so.1
ELF 7db60000-7dbfb000 Deferred libfreetype.so.6
ELF 7dc18000-7dc88000 Deferred setupapi<elf>
\-PE 7dc20000-7dc88000 \ setupapi
ELF 7dc88000-7dcbe000 Deferred wintrust<elf>
\-PE 7dc90000-7dcbe000 \ wintrust
ELF 7dcbe000-7dce4000 Deferred iphlpapi<elf>
\-PE 7dcc0000-7dce4000 \ iphlpapi
ELF 7dce4000-7dd11000 Deferred netapi32<elf>
\-PE 7dcf0000-7dd11000 \ netapi32
ELF 7dd11000-7dd44000 Deferred secur32<elf>
\-PE 7dd20000-7dd44000 \ secur32
ELF 7dd44000-7dd65000 Deferred oleacc<elf>
\-PE 7dd50000-7dd65000 \ oleacc
ELF 7dd65000-7dd89000 Deferred imm32<elf>
\-PE 7dd70000-7dd89000 \ imm32
ELF 7dd89000-7ddb4000 Deferred msacm32<elf>
\-PE 7dd90000-7ddb4000 \ msacm32
ELF 7ddb4000-7de6d000 Deferred winmm<elf>
\-PE 7ddc0000-7de6d000 \ winmm
ELF 7de6d000-7de81000 Deferred psapi<elf>
\-PE 7de70000-7de81000 \ psapi
ELF 7de81000-7dec3000 Deferred usp10<elf>
\-PE 7de90000-7dec3000 \ usp10
ELF 7dec3000-7def9000 Deferred ws2_32<elf>
\-PE 7ded0000-7def9000 \ ws2_32
ELF 7def9000-7df11000 Deferred wtsapi32<elf>
\-PE 7df00000-7df11000 \ wtsapi32
ELF 7df11000-7df4e000 Deferred winhttp<elf>
\-PE 7df20000-7df4e000 \ winhttp
ELF 7df4e000-7df75000 Deferred mpr<elf>
\-PE 7df50000-7df75000 \ mpr
ELF 7df75000-7df8e000 Deferred libz.so.1
ELF 7df96000-7dfab000 Deferred dhcpcsvc<elf>
\-PE 7dfa0000-7dfab000 \ dhcpcsvc
ELF 7dfab000-7e026000 Deferred wininet<elf>
\-PE 7dfb0000-7e026000 \ wininet
ELF 7e026000-7e15a000 Deferred oleaut32<elf>
\-PE 7e040000-7e15a000 \ oleaut32
ELF 7e15a000-7e1fd000 Deferred urlmon<elf>
\-PE 7e170000-7e1fd000 \ urlmon
ELF 7e1fd000-7e215000 Deferred userenv<elf>
\-PE 7e200000-7e215000 \ userenv
ELF 7e215000-7e255000 Deferred winspool<elf>
\-PE 7e220000-7e255000 \ winspool
ELF 7e255000-7e2cf000 Deferred shlwapi<elf>
\-PE 7e260000-7e2cf000 \ shlwapi
ELF 7e2cf000-7e502000 Deferred shell32<elf>
\-PE 7e2e0000-7e502000 \ shell32
ELF 7e502000-7e5ee000 Deferred comdlg32<elf>
\-PE 7e510000-7e5ee000 \ comdlg32
ELF 7e5ee000-7e6f6000 Deferred comctl32<elf>
\-PE 7e600000-7e6f6000 \ comctl32
ELF 7e6f6000-7e777000 Deferred rpcrt4<elf>
\-PE 7e700000-7e777000 \ rpcrt4
ELF 7e777000-7e8b3000 Deferred ole32<elf>
\-PE 7e790000-7e8b3000 \ ole32
ELF 7e8b3000-7e922000 Deferred advapi32<elf>
\-PE 7e8c0000-7e922000 \ advapi32
ELF 7e922000-7ea40000 Deferred gdi32<elf>
\-PE 7e930000-7ea40000 \ gdi32
ELF 7ea40000-7eb9b000 Deferred user32<elf>
\-PE 7ea50000-7eb9b000 \ user32
ELF 7eb9b000-7ec69000 Deferred crypt32<elf>
\-PE 7eba0000-7ec69000 \ crypt32
ELF 7ec69000-7ed5c000 Deferred cryptui<elf>
\-PE 7ec70000-7ed5c000 \ cryptui
ELF 7ed5c000-7ed69000 Deferred libnss_files.so.2
ELF 7ed69000-7ed75000 Deferred libnss_nis.so.2
ELF 7ed75000-7ed8e000 Deferred libnsl.so.1
ELF 7ed8e000-7ed97000 Deferred libnss_compat.so.2
ELF 7ef97000-7efda000 Deferred libm.so.6
ELF 7efda000-7efe3000 Deferred librt.so.1
ELF 7efe6000-7f000000 Deferred version<elf>
\-PE 7eff0000-7f000000 \ version
ELF f7186000-f71ba000 Deferred msctf<elf>
\-PE f7190000-f71ba000 \ msctf
ELF f7306000-f7323000 Deferred libgcc_s.so.1
ELF f7327000-f7340000 Deferred msftedit<elf>
\-PE f7330000-f7340000 \ msftedit
ELF f7344000-f7349000 Deferred libdl.so.2
ELF f7349000-f74fc000 Dwarf libc.so.6
ELF f74fd000-f7518000 Dwarf libpthread.so.0
ELF f7529000-f7530000 Deferred libnss_dns.so.2
ELF f7535000-f76eb000 Dwarf libwine.so.1
ELF f76ed000-f770f000 Deferred ld-linux.so.2
ELF f770f000-f7710000 Deferred [vdso].so
Threads:
process tid prio (all id:s are in hex)
0000000e services.exe
0000001e 0
0000001d 0
00000014 0
00000010 0
0000000f 0
00000012 winedevice.exe
0000001b 0
00000018 0
00000017 0
00000013 0
00000019 plugplay.exe
00000020 0
0000001f 0
0000001a 0
00000021 explorer.exe
00000023 0
00000022 0
00000035 (D) C:\Program Files (x86)\Opera Next\16.0.1196.14\opera.exe
00000053 0
00000050 0
0000004f 0
0000004e 0
0000004d 0
0000004a 0
00000031 0
00000032 0
0000003b 0
00000034 0
0000002e 0
0000002f 0
00000025 0
00000026 0
0000002b 0
00000030 0
0000002c 0
0000002d 0
00000029 0
00000028 0
00000027 0
0000000d 0
00000009 0
0000000b 0 <==
00000047 0
00000046 0
00000045 0
00000044 0
00000043 0
00000042 0
00000041 0
00000040 0
0000003f 0
0000003e 0
0000003d 0
0000003c 0
00000036 0
00000037 opera_crashreporter.exe
0000003a 0
00000039 0
00000038 0
System information:
Wine build: wine-1.6-rc5
Platform: i386 (WOW64)
Host system: Linux
Host version: 3.8.0-26-genericCsak nem akar működni még 1.6-os Wine alatt sem...
-
koti
tag
Szeretnék segítséget kérni. 12.16-os verzió, Win7 Opera alatt valami miatt egyre több oldalt nem nyit meg. 400 Bad Request Request Header Or Cookie Too Large hibát ír. Más böngészőbe pedig megy az oldal. Mit kellene átállítani. Előre is köszönöm. Ha lehet privátban is segítsetek!
-
#20006
Sk8erPeter
nagyúr
Dr_Syrex
#19997
Sk8erPeter
nagyúr
válasz
Dr_Syrex
#19997
üzenetére
"A hétvégétől végre SSD-n fut majd az oprendszerem és természetesen az Opera is.
Mire érdemes a leginkább figyelni és mik a legfontosabb beállítások?"Arra érdemes a leginkább figyelni, hogy ne higgy az olyan úgynevezett SSD-kímélő módszereknek, mint pl. a Windows Search-szolgáltatás kikapcsolása, és hasonlók.
Ezek csak arra jók, hogy szépen kényelmetlenné tegyél dolgokat, és valóban elkerülj mindenféle műveletet, ami pluszban írna vagy olvasna az SSD-ről, de akkor meg minek vettél SSD-t. Mire a jelenlegi SSD-d elhasználódna, addigra egy vinyót is nagy valószínűséggel lecserélnél vagy update-elnél, de mindenesetre addigra egy akkora kapacitású SSD jóval olcsóbb lesz, így az esetleges elhasználódása sem lesz már akkora probléma...A Samsungnak van egy saját optimalizáló szoftvere (Magician), ha ilyen SSD-d van, az hasznos lehet, de értelmetlenül ne kapcsolj ki szolgáltatásokat. Nem hinném, hogy érdemes lenne szívatnod magad RAMDiskkel, csak ha tobzódsz a "felesleges" (?) memóriatartalékban.
Sk8erPeter
-
#20009
whiskeys
őstag
Sk8erPeter
#20008
whiskeys
őstag
válasz
Sk8erPeter
#20008
üzenetére
mindegyik verzio-ra ezt csinálja.... jelenleg 12.16 ...firefox-nál is ez van...
[ Szerkesztve ]
"Jól jegyezd meg,ha egy krokodil a kezedből eszik, az enni fog a lábadból is."
-
LonGleY
veterán
válasz
whiskeys
#20009
üzenetére
Nem, mert pl. a 15+ nem csinálja, mivel WebKit-re optimalizált a Gmail - azon kívül, hogy amúgy szar.
De most majd sokat gyorsul, hogy a különválás miatt a WebKit-ről és a Blink-ről is le tudnak nyesni egy-egy fölös réteget. 1-2 Chrome és Opera verzió még és lőn a kánaán.
[ Szerkesztve ]
-
dqdb
Topikgazda
Ah, most esett le, hogy az O15 vonal valójában kiváló user JS és user CSS támogatással rendelkezik, ahol elég egy mappában fájlokat szerkesztgetni, csak kicsit másképpen kell használni a bővítményeket hozzá
A leírás az angol UI alapján készült, mert lusta vagyok nyelvet váltani. A megoldás rém egyszerű: egy unpacked extensiont kell készíteni a saját szánk íze szerint, így a scriptek az O12-höz hasonlóan fájlban tanyáznak majd localStorage helyett, és a Tampermonkey-Stylish kiegészítők telepítésére nem lesz szükség.Telepítés:
1. töltsd le ezt a ZIP fájlt és csomagold ki egy mappába
2. Operában Ctrl+Shift+E > jobb felső sarokban Developer Mode
3. Load unpacked extension > keresd meg azt a mappát, ahová az előbb kicsomagoltad a fájlokat > OkÚj (vagy korábban O12-ben használt) user CSS hozzáadása:
1. a .css fájlt elmented az extension css mappájában
2. megnyitod az extensionhöz tartozó manifest.json fájlt, és a content_scripts részben készítesz egy kommentek nélküli másolatot az example user CSS blokkról (a struktúrát záró vesszőre kell ügyelni, ha ez az utolsó szabály, akkor nem kell vessző, egyébként igen)
3. a matches értékben vesszővel elválasztva felsorolod azokat az oldalakat/aloldalakat, ahol szeretnéd, hogy éljen a CSS
4. a css értékben megadod a fájl nevét
5. Operában Ctrl+Shift+E > megkeresed a User JS and CSS bővítményt > ReloadKonkrét példa:
1. tegyük fel, hogy a PH főbb oldalain a háttér színét feketére szeretnéd változtatni
2. létrehozod a css mappában a ph.css fájlt a következő tartalommal:body { background: black; }
3. a manifest.json fájl content_scripts részébe a következő kerül (ügyelj a vesszőre a végén):
{
"matches": [ "http://prohardver.hu/*", "http://mobilarena.hu/*",
"http://itcafe.hu/*" ],
"css": [ "css/ph.css" ]
},Stylish kompatibilis user CSS hozzáadása:
1. letöltöd az eredeti .css fájlt a css mappába, és megnyitod valamilyen text editorban
2. megkeresed a @-moz-document sort
3. a megtalált sor alapján kell a manifest.json bejegyzését létrehozni, íme pár példa.eredeti:
@-moz-document domain("facebook.com")átírt:
"matches": [ "*://facebook.com/*" ],eredeti:
@-moz-document url-prefix(http://www.google.com),
url-prefix(http://images.google.com),átírt:
"matches": [ "http://www.google.com/*", "http://images.google.com/*"],4. töröld a .css fájl fejlécét, valamint a CSS szabályokat körülölelő { és } tageket
eredeti:
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document url-prefix(http://prohardver.hu),
url-prefix(http://mobilarena.hu)
{
body { background: black; }
}módosított:
body { background: black; }User JS hozzáadása:
1. elmented a fájlt a js mappában
2. megnyitod az extensionhöz tartozó manifest.json fájlt, és a content_scripts részben készítesz egy kommentek nélküli másolatot az example user JS blokkról (a struktúrát záró vesszőre kell ügyelni, ha ez az utolsó szabály, akkor nem kell vessző, egyébként igen)
3. megnyitod a .js fájlt, és a @include szabályokat felsorolod a matches értékben vesszővel elválasztva
4. opcionálisan a runAt érték definiálásával lehet módosítani a script lefutási idejét
5. Operában Ctrl+Shift+E > megkeresed a User JS and CSS bővítményt > ReloadKonkrét példa (és önreklám
):
1. letöltöd ezt a scriptet redirect_to_gamepod.js néven a js mappába
2. a manifest.json fájl content_scripts részébe a következő kerül (ügyelj a vesszőre a végén):
{
"matches": [ "http://prohardver.hu/*", "http://mobilarena.hu/*",
"http://itcafe.hu/*", "http://logout.hu/*",
"http://gamepod.hu/*" ],
"js": [ "js/redirect_to_gamepod.js" ]
}[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#20017
atillaahun
veterán
atillaahun
veterán
Üdv, ez mi a p*cs szerintetek?
Mondjuk nem csak Opera hozza ezt, hanem pl. Chrome is, de csak bizonyos gépeken, mobilon pl. bejön a pelikan.hu rendesen, meg gondolom nektek is.
[ Szerkesztve ]
-
LonGleY
veterán
válasz
whiskeys
#20015
üzenetére
Az a gyorsító, ha nincs fent semmilyen bővítmény. Vagy
csak az AdBlock Plus, és még ami szükséges. A Chrome-
hoz képest lassabb a Firefox, de ha feltűnően nyögvenyelős,
akkor inkább a géped, szoftveres környezeted a ludas.atillaahun: Adathalász és popupos szarságok miatt szokták
tiltani különféle frissülő listák alapján az oldalakat a böngészők,
a Firefox-ban is van ilyen (phishing filter). De olyan is van, hogy
bizonyos IP-ket, tartományokat a webszerver zár ki. Tipp-tipp-tipp.[ Szerkesztve ]
-
#20019
dqdb
Topikgazda
atillaahun
#20017
dqdb
Topikgazda
válasz
atillaahun
#20017
üzenetére
Elszúrt webszerver-beállítás. Ha beírsz egy címet, ami a webszerveren valójában egy mappára mutat, akkor a következő lehetőségei vannak az üzemeltetőnek:
1. visszaadja a mappa tartalmát (példa itt). Ez a linkelt példához hasonló esetektől eltekintve egyáltalán nem ajánlott megoldás, ezt a viselkedést ma már általában külön kell engedélyezni.
2. átirányít a mappa egy megadott nevű fájljára (erre a PH kezdőoldala jó példa, azonnal az URL végére csapja az index.html részt)
3. hibát dob, mint a fenti esetben vagy itt. Az üzemeltetőn/a használt webszerveren múlik, hogy a visszaadott hiba 403 (nincsen jogosultság) vagy 404 (nem létezik), mindkettő jogos és mindkettőre van bőven példa.Manapság a 2. és 3. megoldás keverékét szokták alkalmazni: a főoldalra a 2. megoldást, míg az aloldalaknál a 3. megoldást. A PH így tesz, a főoldalon automatikusan bekerül az index.html a cím végére, míg egy aloldalon (fórum kezdőlapja hiányosan) jön a hiba.
Másik fontos kérdés az aloldalak közti átirányítás kérdése: sok oldal ragaszkodik a www-mentes címhez, a PH például a www.prohardver.hu címről azonnal a prohardver.hu címre dob át.
A problémás oldalnál egyszerűen elmaradt ez az átirányítás a pelikan.hu címről a www.pelikan.hu címre, mert az utóbbival megy az oldal ...
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#20020
atillaahun
veterán
dqdb
#20019
atillaahun
veterán
-
#20021
dqdb
Topikgazda
atillaahun
#20020
dqdb
Topikgazda
válasz
atillaahun
#20020
üzenetére
Ez egyébként biztosan webserver beállítási hiba? Nem a DNS regisztrátor tolt el valamit?
Jelen esetben a webszerverrel van baj, mert mindkét cím ugyanarra az IP-re mutat. Amúgy jogos a felvetésed, sokszor a DNS feloldás (vagy annak hiánya) a bűnös.Mi egyébként ennek a jelentősége, hogy egy domain csak www-vel működik, csak anélkül, vagy mindkét módon?
A jelentősége a hülyebiztosság Mindegy hogyan írod be a címet, akkor is működik. Az már az üzemeltető döntése, hogy engedi a mixelést, vagy kiválasztja a preferált változatot, és arra irányít át minden lekérést (az átirányítás itt sokszor csak idézőjeles, mert szimplán a HTTP válaszban szerepel az a cím, ahonnan a válasz jött, és a browser arra cseréli le a címet).tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#20025
Dr_Syrex
senior tag
Sk8erPeter
#20006
Dr_Syrex
senior tag
válasz
Sk8erPeter
#20006
üzenetére
Köszönöm. Csak azért voltam rá kíváncsi, mert sokan kötelező dologként ajánlották a "kímélő beállításokat".
De közben eszembe jutott, hogy mivel TuneUp-ot használok a Win7 alatt, ezért a benne lévő turbo mód bármikor ki-be kapcsolható.
Nélam általában 10-20-30 fül van folyamatosan használatban. Ehhez hogy érdemes beálltani a cache méretet a memóriában illetve a lemezen?
Rosetta@home, lépj be Te is a PH! csapatába! *** WoT: Blitzking 43M TURAN - Hungarian Armored Brigade
-
Penge_4
veterán
1. Mennyivel használ ez kevesebb RAM-ot, mint a Stylish és a TamperMonkey?
2. A matches-nél mi a feketelistás megfelelő? Amikor mindenhol le akarom futtatni, kivéve néhány oldalon, akkor megadhatok sima csillagot a matches-nél (ami required a dokumentáció szerint) és az exclude_matches-nél (ami pedig csak optional) a kivételeket?
3. Működik *://www.example.com/* helyett úgy is, hogy http*://www.example.com/* vagy csak az első és utolsó karakter lehet csillag? Mert van, ahol csak http-re és https-re akarom alkalmazni, ftp-re nem.
4. A mindenhol működő mód vonatkozik a localhostra is, amikor pl. helyi html/mht fájlt nyitok meg?A content script limitations-nál nem tetszik ez a rész "Use variables or functions defined by web pages or by other content scripts"
Akkor innentől nem lehet kicsapni oldalakon azt a scriptet, ami ellenőrzi, hogy használsz-e adblockot vagy sem? Ez így nagyon behatárolja a lehetőségeket.
A document_start, document_end és document_idle elég soványnak tűnik az Operás userJS kezelés után. Az abc sorrend szerinti végrehajtás azonos ütemezés esetén itt is működik?
-
Penge_4
veterán
"Ez a linkelt példához hasonló esetektől eltekintve egyáltalán nem ajánlott megoldás, ezt a viselkedést ma már általában külön kell engedélyezni."
Aha, szóval akkor ezért lett hirtelen ez ritka, nem pedig azért, mert az üzemeltetők lettek hozzáértőbbek és biztonságtudatosabbak. Régebben gyakoribb volt és őszintén szólva tök jó volt, hogy egy csomó tartalomhoz hozzá lehetett férni a szarul konfigurált webszervereken (főleg fizetős oldalakon volt jó).
Most meg csak akkor, ha eltalálod a pontos URL-t. Néha még az is tiltva van.
"a visszaadott hiba 403 (nincsen jogosultság) vagy 404 (nem létezik), mindkettő jogos és mindkettőre van bőven példa."
403-nál van olyan, hogy belekattintasz az URL sávba, majd nyomsz egy Entert (gondolom valami cookie eltárolás vagy referrer lehet a háttérben) utána már működik. Általában hotlinkelést tiltó képeknél figyelhető ez meg.
(#20022) Orlin: Nem egészen normális. Normális esetben csak az eggyel korábbi verziót kéne megtartania, a többit törölni.
[ Szerkesztve ]
-
Orlin
addikt
"Okos megoldás a hosszú Google keresőmező eltüntetésére."
Valaki leírná mit kell pontosan csinálni?
Nagyon nem vagyok járatos benne.
Addig értem,hogy meg kell nyitni az about:flags-ot és utána?-enable developer mode
-Load unpacked extension and navigate to folder (extracted in Step-1)Köszi
LENOVO IDEAPAD 5 Pro 16 - Ryzen 5 6600HS, 16, 1000 GB, 16GB, Radeon 660M Graphics, Win11
-
dqdb
Topikgazda
válasz
Penge_4
#20026
üzenetére
Mennyivel használ ez kevesebb RAM-ot, mint a Stylish és a TamperMonkey?
Nem néztem, nem is fogom megnézni, de biztos vagyok benne, hogy kevesebbet. Azzal, hogy egyetlen egyszerű kiegészítő fut kettő bonyolultabb helyett, már -1 folyamat, kevesebb JS kód fog futni, hiszen az állandóan lefutó logika egy része a content_scripts blokk tudásának kihasználásával átkerül natív kódba.A matches-nél mi a feketelistás megfelelő? Amikor mindenhol le akarom futtatni, kivéve néhány oldalon, akkor megadhatok sima csillagot a matches-nél (ami required a dokumentáció szerint) és az exclude_matches-nél (ami pedig csak optional) a kivételeket?
Működik *://www.example.com/* helyett úgy is, hogy http*://www.example.com/* vagy csak az első és utolsó karakter lehet csillag? Mert van, ahol csak http-re és https-re akarom alkalmazni, ftp-re nem.
Íme a dokumentáció, példákkal illusztrálva válaszolnak a kérdéseidre. Csillag bárhol lehet benne, kérdőjel is akár. Sőt, a match mellett az include_globs sort felhasználva még keresztszorzatot is képezhetsz:"matches": [ "http://prohardver.hu/*", "http://mobilarena.hu/*" ],
"include_globs": [ "*/teszt/*", "*/hir/*" ]A fenti szabály hatására kizárólag a PH-n és MA-n, és ott is csak a híreknél és a teszteknél fog lefutni a content script. Éppen most álltam neki egy korábbi user JS átalakítására, mert ezzel a feature-rel user CSS-ből megoldom azt, amire O12 alatt JavaScript kellett.
A mindenhol működő mód vonatkozik a localhostra is, amikor pl. helyi html/mht fájlt nyitok meg?
Localhostra nem kell semmi extra. Helyi fájlokra, ha így adod meg, és beállítod, hogy a file:// címekre is működjön, akkor menni fog:{
"matches": [ "*://*/*", "file://*/*" ],
"css": [ "css/all.css" ]
}A content script limitations-nál nem tetszik ez a rész "Use variables or functions defined by web pages or by other content scripts". Akkor innentől nem lehet kicsapni oldalakon azt a scriptet, ami ellenőrzi, hogy használsz-e adblockot vagy sem? Ez így nagyon behatárolja a lehetőségeket.
Ezzel kapcsolatban van egy ötletem, majd megnézem.A document_start, document_end és document_idle elég soványnak tűnik az Operás userJS kezelés után.
Nekem elég volt eddig mindenre. Persze jól jönne olyan kiegészítés, amivel letöltés után lehetne patchelni scripteket.Az abc sorrend szerinti végrehajtás azonos ütemezés esetén itt is működik?
A sorrendet az határozza meg, hogy te milyen sorrendben definiáltad a scripteket. Ez egyszerre jobb az ABC sorrendnél, mert flexibilisebb, egyszerre rosszabb, mert sorba kell rendezned őket. Az pozitívum a szememben, hogy a szűrőkön fennakadó scriptek már eleve le sem futnak ellentétben a @include-tól mentes user JS-ekkel.Aha, szóval akkor ezért lett hirtelen ez ritka, nem pedig azért, mert az üzemeltetők lettek hozzáértőbbek és biztonságtudatosabbak.
Inkább a kettő között és kapcsolat van, valamint megváltozott az oldalak jellege és működése. A statikus HTML oldalak korában még jól lehetett ezzel boldogulni, az URL rewrite és a dinamikus tartalom miatt már sokra nem mennél azzal, ha ki lenne nyitva ez a kapu. Itt a PH-n sem létezik egyetlen cikk sem fájlként a rendszerben (a képek, scriptek és CSS-ek kivételt képeznek, úgy nézem, ezek a /dl/ mappában vannak), csak a külvilág felé alakul át a ronda paraméterekkel teletűzdelt HTTP GET lekérdezés szép, keresőbarát címmé.403-nál van olyan, hogy belekattintasz az URL sávba, majd nyomsz egy Entert (gondolom valami cookie eltárolás vagy referrer lehet a háttérben) utána már működik. Általában hotlinkelést tiltó képeknél figyelhető ez meg.
Semmi cookie, színtiszta referer. A második kérésnél már az oldal önmaga lesz az előzmény, és mélyebb URL ellenőrzést valószínűleg nem végeznek (nem nézik meg, hogy a saját megjelenítő-oldaluk-e az előzmény, megelégednek a site-tal), ezért jelenik meg a kép.(#20022) Orlin: ahogyan Penge_4 is írja, nem normális. Elvileg törli a korábbi változatokat az Opera frissítés után, és csak a legutolsó kettőt hagyja meg, állítólag egyeseknél ez működik, gyakorlatilag én két gépen hat Opera példányból egyben sem láttam még működni (lehet, hogy a portable mód miatt van).
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Penge_4
veterán
"Helyi fájlokra, ha így adod meg, és beállítod, hogy a file:// címekre is működjön, akkor menni fog:"
Tehát hiába a "*://*/*", a file://-t is külön hozzá kell adnom?
"A sorrendet az határozza meg, hogy te milyen sorrendben definiáltad a scripteket."
Mármint a manifest.json-ban, felülről-lefelé?
"Az pozitívum a szememben, hogy a szűrőkön fennakadó scriptek már eleve le sem futnak ellentétben a @include-tól mentes user JS-ekkel."
Ezt nem értem. Itt a manifest.json-ban definiálod ugyanazt, amit sima userJS-eknél UserJS specifikusan a headerben include-okkal és exclude-okkal. Szóval nem teljesen mindegy, hogy egy központi helyen definiálod, hogy hol futhat le, vagy egyenként? Amit a manifest.json-ban úgy definiálsz, hogy mindenhol fusson le, az ugyanúgy mindenhol lefut, amit pedig úgy, hogy csak adott oldalakon, az ugyanúgy nem, mint a UserJS-ek sem, ahol exclude-olva voltak az oldalak, vagy nem volt egyezés az include-ra.
Amúgy a match meg az include között mi a különbség? Mert UserJS-ben is láttam már
// @match http://example.com/*-t -
dqdb
Topikgazda
válasz
Penge_4
#20030
üzenetére
Tehát hiába a "*://*/*", a file://-t is külön hozzá kell adnom?
Pontosan. Kissé idióta megoldás, a * nem mindent jelöl, hanem csak http-t és https-t:"If the scheme is *, then it matches either http or https."
[link]Mármint a manifest.json-ban, felülről-lefelé?
Felülről lefelé, és szabályon belül balról jobbra.Szóval nem teljesen mindegy, hogy egy központi helyen definiálod, hogy hol futhat le, vagy egyenként?
Elvileg igen, gyakorlatilag így azonnal átlátom az egészet. Ráadásul ehhez csak szimplán JSON-t kell parse-olni, ami
1. sokkal egyszerűbb egy komplett JS-nél, és abban egy megjegyzésbe ágyazott, további parse-olást igénylő metaadatnál
2. van szintaktikai ellenőrzésAmúgy a match meg az include között mi a különbség?
Valószínűleg csak más nyelvjárás. Én mindig az @include-@exclude párost használtam.---------
Feltűnően megváltozott a hangulat a Desktop Team blogon. Haavard eltűnt, de több fejlesztő is aktív, a javaslatokra sokszor jön a már készül , jó ötlet, bekerül vagy jó ötlet, felírtuk a listára válasz. Érdemes végigolvasni az O16 release topikját, sok biztató infót elhintettek így:
* a fülek feletti 1 pixel konfigurálható lesz
* a Ctrl+szám billentyűk bekerülnek
* lesz lehetőség a teljes címsor megjelenítésére, ezt valószínűleg a developer tools bekapcsolásához kötik majd
* a keresők szerkesztőfelülete készül
* formoknál határozottan megfontolják az autocomplete="off" attribútum felülbírálhatóságának megvalósításátÉs így tovább, hirtelen ezek jutottak az eszembe. Egy dologgal nem találkoztam, ami nekem jelenleg fáj: volt valahol szó arról, hogy letöltésnél a mostani kötelező mentés helyett a korábbihoz hasonló open/save/cancel ablakot kapunk majd?
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
Topikgazda
Még pár dolog, ami eszembe jutott:
* induláskor szabályozható lesz, hogy üresen vagy a korábbi fülekkel induljon a böngésző (üdv O12 feature)
* erre a képre az volt a reakció, hogy a developer csatornán hamarosan megjelenik egy ilyen opció (üdv FF feature, nem értem, eddig miért nem oldották meg)
* a könyvjelzőknél lesznek nickek"Don't forget about shortcuts/nicknames for bookmarks."
"Surly we will not. Users remind that to us each day
"tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
Topikgazda
válasz
attisx
#20033
üzenetére
Igen, bár az O16-ban már nem várható új feature, csak hibajavítás. Most úgy érzem, hogy O18-19 környékén már egész pofás lesz ismét a böngésző.
Ez a kedvenc hivatalos válaszom:
"I'd like to ask the inverse roadmap question: are there any features of O12 you already know you will not work on for Opera 16+ because you consider them unnecessary or too complicated?"
"Things change rapidly. 2 months ago nobody really considered bookmarks, and now they are under development."
Ezek szerint komolyan gondolták, és tényleg elhitték, hogy nincsen szükség könyvjelzőkre egy böngészőben.
Még két apróság:
* felkerült a végeláthatatlan listára, hogy a Discovery alá fel lehessen venni saját feedet (bár a Feedly Cloud mellett nekem már nem fáj az RSS olvasó hiánya annyira)
* "We haven't got enough time yet to put that much work to support the low end devices ... Further performance improvements for these devices is high on our priority list."[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
-
#20037
Sk8erPeter
nagyúr
dqdb
#20016
Sk8erPeter
nagyúr
De most ebben nem nagyon értem, mi az újdonság, pont ezt magyaráztam priviben, hogy nem értem, miért akkora érvágás, hogy kiszedték a userJS- és userCSS-támogatást, mivel simán át lehet írni extensionre.
Pont így, ahogy leírtad. Na mindegy, legalább valaki leírta magyarul is. Sk8erPeter
-
#20038
Sk8erPeter
nagyúr
dqdb
#20019
Sk8erPeter
nagyúr
"Manapság a 2. és 3. megoldás keverékét szokták alkalmazni"
A 2. ponthoz: igazából egyáltalán nem kell, hogy ÁTIRÁNYÍTÁS történjen, általában elég megadni default fájlOKat is a webszervernek, amik potenciálisan a kezdőlapot szolgálhatják ki, így például az "index.html" rész simán rejtve maradhatna. Apache-nál ez a DirectoryIndex direktíva (van egy default beállítás, meg VirtualHostra vonatkozó beállítás, aztán .htaccess-ben felül lehet bírálni, amennyiben ez engedélyezett), amiben egymás után felsorolhatod a keresendő fájlok neveit (ha az első nincs meg, ugrik a másodikra, ha az sincs, a harmadikra, és így tovább).Sk8erPeter
-
#20039
Sk8erPeter
nagyúr
dqdb
#20021
Sk8erPeter
nagyúr
">>Mi egyébként ennek a jelentősége, hogy egy domain csak www-vel működik, csak anélkül, vagy mindkét módon?
A jelentősége a hülyebiztosság Mindegy hogyan írod be a címet, akkor is működik."
Nem csak a hülyebiztosság, elméletileg SEO szempontjából is számít (még ha meglepő is). Egy oldal üzemeltetője mindig döntse el, hogy www-vel vagy anélkül kívánja használni az oldalát, és ragaszkodjon hozzá, de mindkét formátum legyen megfelelően kezelve, és például egy egyszerű RewriteRule-lal vagy hasonló módon legyen megoldva az átirányítás.Szerk.: OFF.
[ Szerkesztve ]
Sk8erPeter
-
#20040
Sk8erPeter
nagyúr
Penge_4
#20027
Sk8erPeter
nagyúr
válasz
Penge_4
#20027
üzenetére
"Régebben gyakoribb volt és őszintén szólva tök jó volt, hogy egy csomó tartalomhoz hozzá lehetett férni a szarul konfigurált webszervereken (főleg fizetős oldalakon volt jó)."
Úgy értette, hogy a webszervereken manapság a default beállítás a gyökérbiztos beállítás, mivel egy Apache-ot vagy IIS-t is akárki képes beüzemelni, olyan is, akinek fingja sincs a megfelelő webszerver-beállításokról, de akárkinek lehet webszervere otthon, ha nagyon akarja (Options a vonatkozó direktíva, az Options +Indexes hatására felülbírálható a default beállítás, amennyiben ez engedélyezett (pl. ha egy szervernél (lásd pl. osztott tárhelyek) több oldal is üzemel, ott van, hogy a fejlesztő eldöntheti, adott könyvtárban szeretne-e mégis listázást az alapértelmezett tiltás ellenére, ezt az előbb írt sor beírásával megteheti egy .htaccess-fájlban, szóval nem túl bonyolult)
IIS-nél is alapból tiltott (lásd directoryBrowse értéke alapból false)."403-nál van olyan, hogy belekattintasz az URL sávba, majd nyomsz egy Entert (gondolom valami cookie eltárolás vagy referrer lehet a háttérben) utána már működik. Általában hotlinkelést tiltó képeknél figyelhető ez meg."
Jaja, ez a referer miatt van így (nem cookie-val szokás megoldani).Sk8erPeter
-
#20041
Sk8erPeter
nagyúr
dqdb
#20029
Sk8erPeter
nagyúr
"Ez egyszerre jobb az ABC sorrendnél, mert flexibilisebb, egyszerre rosszabb, mert sorba kell rendezned őket."
Miért, az ABC-sorrendbe rendezésnél mit csináltál, ha nem sorbarendezted őket?
"Itt a PH-n sem létezik egyetlen cikk sem fájlként a rendszerben"
Hát az elég vad lenne, ha a Prohardveren fájlokba írogatnák, és azokból olvasgatnák a cikkeket adatbázisba írogatás és abból olvasás helyett...
"Feltűnően megváltozott a hangulat a Desktop Team blogon. Haavard eltűnt, de több fejlesztő is aktív, a javaslatokra sokszor jön a már készül , jó ötlet, bekerül vagy jó ötlet, felírtuk a listára válasz"
Na végre!
Örülök, hogy jó hírek is szárnyrakaptak, bár mióta a 15-ös kijött, irtózom az Operától, egyáltalán nem használom, max. 1 hónapban egyszer, sajnos nálam feketelistára került, de remélhetőleg pár verzió múlva lesz miért hozzányúlnom. Addig marad a Chrome.[ Szerkesztve ]
Sk8erPeter
-
#20042
Penge_4
veterán
Sk8erPeter
#20041
Penge_4
veterán
válasz
Sk8erPeter
#20041
üzenetére
"Hát az elég vad lenne, ha a Prohardveren fájlokba írogatnák, és azokból olvasgatnák a cikkeket adatbázisba írogatás és abból olvasás helyett..."
Miért? A hozzászólásoknál (hsz_20001-20050.html vagy friss.html) még oké, mivel dinamikus tartalom. De a cikkek statikusak maradnak. Szóval akár simán lehetne 1-1 statikusan behívott .html fájl is, nem?
(#20034) dqdb: "Ezek szerint komolyan gondolták, és tényleg elhitték, hogy nincsen szükség könyvjelzőkre egy böngészőben."
Mindig újra és újra képes vagyok meglepődni azon, hogy egyes fejlesztők (meg úgy főleg a menedzsment) mennyire el vannak rugaszkodva a valóságtól és mennyire halvány fingjuk nincs a felhasználási szokásokról, holott nekik ott van egy baromi átfogó statisztika is, ami torzít, de azért mégis statisztika. Mi pedig maximum a környezetünk felhasználási szokásaiból tudunk következtetéseket levonni.
[ Szerkesztve ]
-
#20043
dqdb
Topikgazda
Sk8erPeter
#20038
dqdb
Topikgazda
válasz
Sk8erPeter
#20038
üzenetére
De most ebben nem nagyon értem, mi az újdonság, pont ezt magyaráztam priviben, hogy nem értem, miért akkora érvágás, hogy kiszedték a userJS- és userCSS-támogatást, mivel simán át lehet írni extensionre.
Számomra annyi volt benne az újdonság, hogy unpacked extensionnel lényegében a korábbi User JS és CSS funkcionalitást (azaz fájlokban van minden egy mappában) lehet hozni minimális pluszmunkával. Szóval egy csecsemőnek minden új, nekem az erre és így felismerése volt az újdonság. My Operán meg is jegyeztem egy Opera fejlesztőnek, hogy szerintem érdemes lenne erről a megközelítésről egy rövidebb cikket írniuk (még most is sokan hiányolják megjegyzésben a User JS+CSS párost).A 2. ponthoz: igazából egyáltalán nem kell, hogy ÁTIRÁNYÍTÁS történjen, általában elég megadni default fájlOKat is a webszervernek ...
Enyhén pongyola volt a megfogalmazásom: átirányítás alatt értettem mindazt, amikor nem pontosan azt kapod, amit kértél (HTTP 3xx, Location a válasz fejlécében, vagy pusztán másik tartalom). Hú, de rég konfiguráltam már Apache-ot, pedig korábban még saját modult is írtam hozzá egy projekt miatt ...Nem csak a hülyebiztosság, elméletileg SEO szempontjából is számít (még ha meglepő is).
Erre nem is gondoltam volna, kösz az infót! Látszik, hogy nem a webfejlesztés terén mozgok. Szerintem a mod_rewrite az Apache legnagyobb találmánya volt anno.Miért, az ABC-sorrendbe rendezésnél mit csináltál, ha nem sorbarendezted őket?
Ott csak akkor kellett gondolkozni és cselekedni, ha volt két script között függőség, egyébként szimpla fájlmásolást igényelt. Most minden újabb script két másodpercbe kerül, mert át kell gondolni a logikai sorrendetPenge_4: De a cikkek statikusak maradnak. Szóval akár simán lehetne 1-1 statikusan behívott .html fájl is, nem?
"Élmény" lenne a keresés (minden módosítás után újra kellene indexelni a fájlt) és a designváltás is. Ahol tartalmat szolgálnak ki, ott statikus fájlként a képek (a méretük miatt sokszor nem éri meg őket adatbázisba rakni) és a scriptek léteznek csak (és ezek jelentős része is a memóriában csücsül cache-elve), minden más adatbázisban. Senki sem a saját maga ellensége.Penge_4: erről esetleg tudsz valamit: volt valahol szó arról, hogy letöltésnél a mostani kötelező mentés helyett a korábbihoz hasonló open/save/cancel ablakot kapunk majd?
[link]
Ha valaki O15/16 alatt módosítani szeretné a gyorshívó ikonok méretét és a maximálisan megjeleníthető oszlopok számát. Szép megoldás nincsen rá, ezzel a programmal az opera.pak fájlt patchelem meg, szóval minden Opera frissítés után le kell futtatni.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#20044
Sk8erPeter
nagyúr
Penge_4
#20042
Sk8erPeter
nagyúr
válasz
Penge_4
#20042
üzenetére
"Miért? A hozzászólásoknál (hsz_20001-20050.html vagy friss.html) még oké, mivel dinamikus tartalom. De a cikkek statikusak maradnak. Szóval akár simán lehetne 1-1 statikusan behívott .html fájl is, nem?"
Nem, nagyon amatőr megoldás lenne. Kezdő webfejlesztők szoktak ilyesmivel játszani, de aztán ők is gyorsan rájönnek, hogy ez nem járható út manapság (ha egy nagyon egyszerű bemutatkozó oldal állna 4-5 darab valóban statikus tartalomból, akkor talán, de már akkor is érdemes inkább az összes tartalmat dinamikusan kezelni, mivel egy oldal úgyis mindig bővül, úgyis kell hozzá admin-felület (jó, megjeleníthető WYSIWYG-szerkesztő sima fájlszerkesztéshez is, csak nem érdemes), és így tovább), főleg, hogy az ilyen célra használt fájlkezelés idővel borzalmasan erőforrás-igényes lesz (minden fájlkezelési mechanizmus rendszerhívást eredményez, ami kontextusváltással jár, stb.), lassú, ezenkívül nagyon ocsmány és szétszórt fájlrendszert eredményez, szemben azzal, hogy az adatbázisokat igyekeznek szénné optimalizálni, gyorsabbak, rugalmasabbak, könnyen tudsz pillanatok alatt akár többmillió rekordban is keresni (megfelelő indexeléssel), összetett lekérdezéseket tudsz összeállítani és lefuttatni, kapcsolatokat tudsz teremteni más táblákkal, így például tagelheted a cikket (a cikknek van egy azonosítója, a tagnek is van egy azonosítója, és ezeket egy kapcsolótáblával összehozod), és számtalan más metaadattal láthatod el (például cím, rövid leírás, dátum, szerző (mármint annak általában az id-je, mivel a szerző egyben user is), melyik csoportba tartozik a cikk (ez is egy id), mik a kapcsolódó cikkek, és így tovább), nincs olyan nagyon béna korlátja a dolognak, hogy a fájl nevének kellene tartalmaznia a címet, miközben a fájl neve pedig limitált, ezenkívül a cikk maga is dinamikus kell, hogy legyen, különben nehéz lenne eldönteni, melyik jelenjen meg a címlapon, milyen időrendben legyen, melyik kategóriába tartozik, és így tovább, és ezek csak az első szempontok, amik beugrottak, még biztos ezernyi érvet lehetne felsorolni az adatbázisok mellett a bénácska fájlkezeléssel szemben. Tehát mivel mindezeket "tudja", ilyen értelemben maga a cikk sem statikus.
Ahogy már dqdb is említette, minden felhasználó- és keresőbarát URL mögött van egy leképezés egy csúfabb, de a kódod által "megértett", lekezelt URL-re, ami tartalmazza mondjuk az adatbázisban szereplő id-t és egyebeket.Sk8erPeter
-
#20045
Sk8erPeter
nagyúr
dqdb
#20043
Sk8erPeter
nagyúr
"Enyhén pongyola volt a megfogalmazásom: átirányítás alatt értettem mindazt, amikor nem pontosan azt kapod, amit kértél (HTTP 3xx, Location a válasz fejlécében, vagy pusztán másik tartalom). "
A Prohardver esetében jól fogalmaztál, mert ott tényleg történik egy 301-es átirányítás:
amiről viszont én beszéltem, az az általános tendencia, hogy csak megadnak több alapértelmezett kezdőlapot (index.html, index.php, stb.), és ezeket keresi az adott könyvtárban a webszerver (éppen ezért lehetne egy oldal kezdőlapja pityipalko.html is, közel sem biztos, hogy index.html vagy index.php lesz, ASP.NET-nél pl. Default.aspx szokott lenni a kezdőlap az alapértelmezett webszerver-beállítás szerint, és ez is felülbírálható web.config fájlban, amennyiben engedélyezett), és nem történik semmiféle 3xx HTTP-kód keretében történő átirányítás, lásd pl. Stack Overflow kezdőlapjának megnyitása sima 200 OK-val:
A Prohardvernél nem tudom, minek történik meg ez a 301-es átirányítás az index.html-re, igazából mire jó ez, először arra gondoltam, hogy mobilos detektálás miatt történik mindig egy átirányítás, vagy a sima prohardver.hu/index.html-re, vagy pedig az m.prohardver.hu/index.html-re, de kipróbáltam okostelóval, nem ez történik. Legalábbis nálam nem irányított át a mobilos változatra, nem tudom, másnál mi a helyzet. Ilyen esetben viszont nem tudom, mi értelme van.
A www versus www nélküli magyarázatnál a SEO-s szempontot egyébként úgy értettem, hogy ne legyen mindkettő, mert az egy másik URL, a Google pedig mindkettőt bejárhatja, és azt duplikált tartalomnak érzékelheti, és azt nem szereti (bünti a találati listában). Most rákerestem, itt nálam bőségesebben magyarázza el valaki, mégis tömören:
http://webmasters.stackexchange.com/questions/11560/seo-preference-for-www-or-http-protocol-redirection-do-www-websites-rank-bet/11566#11566
Azért egészítettem ki, nehogy valaki félreértse, és arra gondoljon, hogy egyik vagy másik előnyösebb SEO-szempontból, nem az, sőt, ilyen szempontból tök mindegy, használja-e valaki a www-t vagy sem, csak annyi a lényeg, hogy az ember ragaszkodjon valamelyik formátumhoz.
Én egyébként azt preferálom, hogy ne kelljen kirakni a www-t, mert számomra elavult, ezért én általában a www nélküli változatra irányítom át a usert, de van, akinek a www-s változat tetszik jobban. Tényleg csak ízlés kérdése."Ott csak akkor kellett gondolkozni és cselekedni, ha volt két script között függőség, egyébként szimpla fájlmásolást igényelt. Most minden újabb script két másodpercbe kerül, mert át kell gondolni a logikai sorrendet
"
Ezt most nem nagyon értem, korábban elnevezés alapján tudott az ember felállítani egy sorrendezést, nem? Tehát pl. aaascript.js és bbbscript.js jellegű elnevezéseket is adhatott az ember, az aaascript.js nagyobb prioritást élvezett, hozzáteszem, elég degenerált ez a módszer szerintem, amikor fájlnevekhez van az ember kötve.
Sosem értem, egy ilyen béna konvenciót miért sírnak vissza az emberek, de ízlések és pofonok különböznek. Most a manifest.json-ben úgy adod meg, ahogy akarod, olyan fájlnévvel, ahogy akarod, a sorrendet te döntöd el, nem pedig a fájlnév.Amúgy amit leírtál, annál tudtommal mindig újra kell tölteni az extensiont a manifest.json-be történő új fájl belepakolásakor, nem? De ha jól emlékszem (na erre lehet, hogy rosszul), a user JS-eknél sem volt másképp, csak ott magát a progit kellett úgy, ahogy van, újraindítani. De javíts ki, ha ez téves.
Sk8erPeter
-
#20046
Penge_4
veterán
Sk8erPeter
#20045
Penge_4
veterán
válasz
Sk8erPeter
#20045
üzenetére
"Google pedig mindkettőt bejárhatja, és azt duplikált tartalomnak érzékelheti, és azt nem szereti (bünti a találati listában)."
Szerintem van már annyira fejlett az algoritmusa, hogy a csak www-ben különböző (de még a www2, www3 és társai) URL-eket nem csaló duplikátumnak érzékeli, hanem balfasz duplikátumnak, ezért nem jár érte bünti. Elvégre a sponsored linkeket leszámítva a Google-nak az az érdeke, hogy azokat a népszerűbb oldalakat hozza előre. Tehát ilyen már maximum annyit fog jelenteni, hogy 22. helyett 30. leszel a listában az amúgy full Google barát oldaladdal, míg az első 10-ben akár teljesen összegányolt oldalak is lehetnek csak azért, mert baromi jó a Pagerank-jük és emiatt generálják önmaguk népszerűségét. Na meg a negatív reklám effektus itt is megvan. Pl. közzéteszi az ember ilyen-olyan nagyobb fórumokon, hogy "Figyeljetek már, van ez az example.com. Iszonyatosan gány, hulladék oldal. Aztán jön egy kilométeres hibalista." Ez pedig szépen +1 megjelenést jelent a PageRank algoritmusban. Még a nofollow-ot is figyelik, csak azt jóval kisebb súllyal.
"Sosem értem, egy ilyen béna konvenciót miért sírnak vissza az emberek, de ízlések és pofonok különböznek."
Azért, mert ott nem kellett manifest.json-nal mókolni, hanem egyszerűen név alapján futott le. Itt meg a manifest-ben ellenőrizd a központi jogosultságokat, meg a sorrendet, a scriptben a script saját forráskódját.
Régen természetes volt az átnevezés már csak azért is, mert egyszer userscripts.org-ról ID.user.js néven töltődtek le a scriptek, egy számsorról meg ha sok volt belőle nem tudtam ránézésre, hogy az most mit csinál. Másrészt a example.js néven natívan futott a JS, míg example.user.js néven Greasemonkey emulációban.
Szóval adta magát, hogy innentől ha valaminél feltétlenül fontos, hogy gyorsabban fusson le a többitől, akkor kap a neve mögé egy 0-t vagy egy a betűt.
"De ha jól emlékszem (na erre lehet, hogy rosszul), a user JS-eknél sem volt másképp, csak ott magát a progit kellett úgy, ahogy van, újraindítani. De javíts ki, ha ez téves."
Nem kellett semmi ilyesmit. Csak az oldalt kellett újratölteni. UserCSS-nél kellett újraindítani, ha töröltél vagy hozzáadtál újat. De ha meglévőt módosítottál (pl. adblocker.css-t szerkesztetted), akkor csak egy Reload stylesheets parancs kellett. Ez mondjuk nem tudom bug vagy nem, de ilyenkor újratöltötte a CSS-t minden megnyitott fülön. Azaz mondjuk 50+ tabbal picit megröccent a böngésző, de ennyi. Nem kellett újraindítani ehhez sem.
Sőt, INI szerkesztéseknél (menu, toolbar, skinek, mouse, keyboard) sem kellett újraindítani, csak át kellett váltani Operán belül egy másik INI-re addig, amíg a módosítandó INI-t módosítottad, majd elmentetted a változásokat. Utána visszaváltottál a módosított INI-re, Operán belül, újraindítás nélkül.
Na az ilyeneket hiányolom nagyon az újból. Mintha valami gányolt szar lenne ez a Chromium (mint a Windows), hogy minden apróságért újra kell indítani, miközben létező bizonyíték van/volt rá (Opera/Linux), hogy lehet ezt csinálni másképp is: Vagyis csak feltétlenül szükséges esetben újraindítani.
-
#20047
Sk8erPeter
nagyúr
Penge_4
#20046
Sk8erPeter
nagyúr
válasz
Penge_4
#20046
üzenetére
Hát ha találsz erről valahol egy komolyabb cikket, amit írtál a SEO-val kapcsolatban, a Google keresőrobotjáról, duplikált tartalomról, akkor elhiszem, addig viszont azt hiszem el, amit elég sok helyen alátámasztva olvastam, mégpedig hogy duplikált tartalomnak érzékelheti. Korábban is feltételes módot használtam, ergo ez nem száz százalékos, hogy nagyon lecsúszol a találati listán, de megvan az esély rá, és egy ilyen dolog elég súlyos következményekkel járhat egy komolyabb cég számára.
"Tehát ilyen már maximum annyit fog jelenteni, hogy 22. helyett 30. leszel a listában az amúgy full Google barát oldaladdal"
Ekkora csúszás? Szerinted ez megengedhető egy magát komolyan vevő cég számára? Nagyon nem, ez rengeteg hátrányt jelent, ami anyagiakban is jelentkezhet. (Gondolj akár egy pornós oldalra, számukra ez végzetes lehet. ) Eleve az első találati lapnál nem nagyon szeretnek továbblapozni az emberek, de még lefelé görgetni sem. De ha már lapoznak, akkor legalább azonbelül ne legyen annyira szar helyen..."az első 10-ben akár teljesen összegányolt oldalak is lehetnek"
Attól függ... azért a SEO nem véletlenül egy külön szakma, amihez érteni kell (igaz, sokszor ezek ismétlődő robotmunkák, amiket át kell nézni, hogy stimmel-e), ha valaki tudja, mitől döglik a légy, akkor eléggé előre tudja tolni az adott oldalt. Nyilván mindenhol vannak rossz példák. De most igazából ez nem tudom, hogy jött ide, arról kezdtünk beszélni, hogy el kell dönteni, valaki www-vel vagy anélkül használja-e az oldalát, mert ez számíthat SEO-szempontból, és ennyi, hogy ki mitől kerül előre pontosan, az már egy óriási lista lenne, nem is biztos, hogy van értelme erről itt beszélgetni."Azért, mert ott nem kellett manifest.json-nal mókolni, hanem egyszerűen név alapján futott le. Itt meg a manifest-ben ellenőrizd a központi jogosultságokat, meg a sorrendet, a scriptben a script saját forráskódját."
És a manifest.json fájlban mégis mi a "mókolás"? Semmi. Ez pont az egyik elég kellemes találmánya a Chrome Extension API-nak, hogy értelmesen meg lehet adni ezeket a beállításokat, ilyen gyökérségek nélkül, mint a fájl béna átnevezgetése. A második idézett mondatoddal pedig pont alátámasztottad, mennyivel jobb, hogy szét vannak választva a felelősségek."Szóval adta magát, hogy innentől ha valaminél feltétlenül fontos, hogy gyorsabban fusson le a többitől, akkor kap a neve mögé egy 0-t vagy egy a betűt."
Hát ez valóban csodálatos. A keveredő, ezerféle, egyénenként "sokkal jobbnak" talált katyvasz névkonvenciók használatának gyönyörű melegágya."Mintha valami gányolt szar lenne ez a Chromium (mint a Windows), hogy minden apróságért újra kell indítani"
Kár, hogy pont azt magyaráztam, hogy a Chrome-ot/Chromiumot NEM kell újraindítani ahhoz, hogy egy extensiont újratölts. Rámész az extensionök oldalára, kiszeded a pipát az engedélyezés mellől, majd újra berakod a pipát, ekkor újra betöltődik a memóriába, és kész. Mi ezen a bonyolultabb?
Értem én, hogy idegesít, hogy például a flags oldalon mindenféle beállításhoz újra kellett indítani a böngészőt, ezzel egyet is értek, de ennek semmi köze az extensionökhöz. Ha lehet dicsérni valamit a Chromium-vonalon, akkor az épp az extension API, amiben egész gyorsan lehet fejleszteni, szemben az Opera egykori borzalmasan undorító extension API-jával, de annak idején beszéltünk is erről. Lehet szidni a Google-t sok mindenért, de a fejlesztői API-kat speciel elég jól szokták kitalálni.Sk8erPeter
-
#20048
dqdb
Topikgazda
Sk8erPeter
#20045
dqdb
Topikgazda
válasz
Sk8erPeter
#20045
üzenetére
Az átirányításokról és az alapértelmezett kezdőlapról köszi a részletes leírást, hasznos volt, igaz nekem nulla újdonságot mondtál vele
Ha "szép" átirányítást szeretnél látni, akkor Origó: nekik az origo.hu címből két hoppal jött össze a http://www.origo.hu/index.html
Sosem értem, egy ilyen béna konvenciót miért sírnak vissza az emberek, de ízlések és pofonok különböznek. Most a manifest.json-ben úgy adod meg, ahogy akarod, olyan fájlnévvel, ahogy akarod, a sorrendet te döntöd el, nem pedig a fájlnév.
Ööö, én is ez írtam, mert pont ezen a véleményen vagyokKár, hogy pont azt magyaráztam, hogy a Chrome-ot/Chromiumot NEM kell újraindítani ahhoz, hogy egy extensiont újratölts. Rámész az extensionök oldalára, kiszeded a pipát az engedélyezés mellől, majd újra berakod a pipát, ekkor újra betöltődik a memóriába, és kész. Mi ezen a bonyolultabb?
Még ennél is egyszerűbb: O15-ben unpacked extensionnél elég a Reload gombot megnyomni. Ennek hatására a content scriptek közül a CSS-ek azonnal érvénybe lépnek, a JS-ekhez újra kell tölteni a fület. Nagyon kényelmes fejlesztés közben használni (ráadásul nekem a mostani ideiglenesnek szánt Web Inspector is jobban kézre áll, mint a Dragonfly).Értem én, hogy idegesít, hogy például a flags oldalon mindenféle beállításhoz újra kellett indítani a böngészőt, ezzel egyet is értek, de ennek semmi köze az extensionökhöz.
Idegesítő, de jogos is egyben. Ha az újraindítás nélküli engedélyezés fejlesztési igénye sokkal nagyobb, mint amennyit az adott funkcióra rászánnának, akkor oldják meg így inkább ahelyett, hogy neki sem állnak.Ha lehet dicsérni valamit a Chromium-vonalon, akkor az épp az extension API, amiben egész gyorsan lehet fejleszteni.
Tökéletesen egyetértek Logikus a felépítése, jól dokumentált, használható példaprogramok vannak hozzá, csak egyet tudok érteni. Igaz, vannak még nagy fehér foltok a bővíthetőség területén, de rajta vannak a témán a fejlesztők. Az Opera is elkezdte lassan visszalapátolni a hiányzó API-kat, egyre több Chrome bővítmény fog futni alatta.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#20049
Sk8erPeter
nagyúr
dqdb
#20048
Sk8erPeter
nagyúr
Ja, OK, azt hittem, neked is hiányzik a régi fájlátnevezgetős módszer, akkor pont félreértettem.
Nagyon jó ez a manifest.json-ös megoldás."Még ennél is egyszerűbb: O15-ben unpacked extensionnél elég a Reload gombot megnyomni."
Jogos, erről meg is feledkeztem, úgy írtam, hogy épp nem volt előttem, ezért kimaradt, de természetesen ez Chromium/Chrome-vonalon is ugyanígy van (mondjuk nem túl meglepő, ha már O15 is egy Chromium-variáns)."ráadásul nekem a mostani ideiglenesnek szánt Web Inspector is jobban kézre áll, mint a Dragonfly"
A Chrome fejlesztőpanele mindig is sokkal jobb volt, mint a Dragonfly, utóbbi mindig megmaradt egy gyenge utánzatnak. Sokáig még azt sem tudta, hogy a konzolra kiírjon egy nyomorult objektumot ember által olvasható formába, csak az [object Object] feliratot kaptam eredményül - elképesztő béna. Aztán végre belerakták, miután felfedezték, hogy egy elementáris jellegű dolgot nem ártana tudnia a fejlesztőpanelnek (Chromium/Chrome fejlesztőpanele természetesen már régesrég tudta, de eleve gáz, hogy egyáltalán erről beszélni kell a Dragonfly esetében). Még rengeteg ilyen apróság volt, amiket fejlesztgetés közben fedeztem fel, és rohadtul idegesített, miközben megszoktam a másik fejlesztőpanelnél, de a legnagyobb bajom akkor is az volt, hogy nem lehetett több példányban, oldalanként futtatni a Dragonfly-t. Magyarul tehát két oldalt egymástól függetlenül nem lehetett Operában debuggolni... Szánalom. És a legszomorúbb az egészben, hogy ezt nem is sikerült megvalósítaniuk.
Éppen ezért nagyon sajnálom, ha a mostani fejlesztőpanelt ideiglenesnek szánják, de majd ki akarják dobni, és valami saját fejlesztést akarnak a helyére tenni, mert eddig nem nagyon jött össze Operáéknak."Ha az újraindítás nélküli engedélyezés fejlesztési igénye sokkal nagyobb, mint amennyit az adott funkcióra rászánnának, akkor oldják meg így inkább ahelyett, hogy neki sem állnak."
Igen, mondjuk a flags oldalon tipikusan olyan jellegű dolgokat lehet kapcsolgatni, amik komolyabb változtatásokat jelentenek a renderelésben, hardveres gyorsítással és hasonlókkal kapcsolatosakat. Van persze kivétel, de a lényeg, hogy nem annyira meglepő, hogy ezekhez újra kell indítani a programot. Ahogy Operában is voltak ugyanígy a renderelést befolyásoló változtatások, amik érvénybe lépéséhez a programot újra kellett indítani. Ezen tehát felháborodni nem túl értelmes, és nem ez rontja a böngésző minőségét.
Inkább az egyéb beállítások hiánya.
Nem értem, hogy lehetne tehát ebből következtetni arra, hogy gány lenne a program vagy a böngészőmotor."Logikus a felépítése, jól dokumentált, használható példaprogramok vannak hozzá, csak egyet tudok érteni. Igaz, vannak még nagy fehér foltok a bővíthetőség területén, de rajta vannak a témán a fejlesztők. Az Opera is elkezdte lassan visszalapátolni a hiányzó API-kat, egyre több Chrome bővítmény fog futni alatta."
Na, ez jó hír. Furcsa is volt a Chromium forkolása után, hogy mennyire kiherélt az extension API az Opera 15-ben (bár beszéltünk róla, hogy inkompatibilitási parák merülhettek fel, ezért jobbnak látták valszeg inkább letiltani). Az extension API-val és dokumentációval meg a Google szerintem tényleg kiemelkedik, ahogy Te is írtad, tényleg példamutató értékű, hogy mennyi kód és magyarázat található a doksiban, hogy kezdők/haladók is megérthessék, és nem csak úgy "kiderül" a működése sok próbálgatás után. Mondjuk ahogy írtam is, eddigi tapasztalataim alapján a Google úgy általában is elég erős API-k és hozzá tartozó dokumentációk készítésében, meg a fejlesztők munkájának segítésében (lásd a Google Maps API-t és a hozzá tartozó rendkívül bőséges dokumentációt (így nagyon egyszerűen tud az ember testreszabott, egyedi jelekkel, tetszőleges helyen lévő buborékokkal ellátott térképeket megjeleníteni az oldalán), a reCAPTCHA-t és támogatását, a Google Analytics-et, Google Webmaster Tools-t, és még jópár dolgot, ami most nem jut eszembe).Sk8erPeter
-
#20050
Penge_4
veterán
Sk8erPeter
#20049
Penge_4
veterán
válasz
Sk8erPeter
#20049
üzenetére
"Éppen ezért nagyon sajnálom, ha a mostani fejlesztőpanelt ideiglenesnek szánják, de majd ki akarják dobni, és valami saját fejlesztést akarnak a helyére tenni, mert eddig nem nagyon jött össze Operáéknak."
Én meg nem, mert eddig 4-ből 4-et nem tudtam megcsinálni a Chrome-os fejlesztői panellel.
- Színt lopni az oldal screenshotjából color pickerrel.
- Resources tabon normálisan, átlátható módon sniffelni, hogy miket kéne kicsapnom, ami nem tartozik az oldalhoz.
- HTTP headert egyszerűen olvasni, lehetőleg nem 8 kattintásból.
- Normális, logikus és átlátható módon CSS-t szerkeszteni egy oldalhoz, mert pl. mindig bele kell kattintani abba a rohadt nagyítóba, hogy kiválaszthassam az oldal elemeit, meg nehézkesebb is a kód szerkesztése, meg okosabb akar lenni, mint én (pl. az általános padding beállításokat is padding-left, padding-right, padding-top és padding-bottom-ra cseréli le, hogy utána már 4 helyen módosíthassam, meg ilyenek.Ja +1: kijelölni bizonyos területeket, amiket onnantól egyenesen bemásolok az adblocker.css-mbe, ha nincs sem egyedi class, sem egyedi id, pl:
HTML[class="sg.hu"]>BODY>DIV[id="center"]>TABLE[width="850"][height="100%"][bgcolor="#FFFFFF"]:nth-child(4)>TBODY>TR>TD[width="100%"][valign="TOP"]:nth-child(3)>DIV[class="cikk"][id="cikk"]:nth-child(4)>CENTER:nth-child(3),Szóval számomra meg pont szar még amellett is, hogy az nekem is tetszik, hogy nem minden tabon aktív a panel, csak ott, ahol bekapcsoltam.
"Nem értem, hogy lehetne tehát ebből következtetni arra, hogy gány lenne a program vagy a böngészőmotor."
Úgy, hogy ami úgy van felépítve, hogy menet közben újratölti a modulokat az a szememben átgondoltabb, mint az, ami ilyen ultimate "indítsd újra" faszságokra hagyatkozik. Egy példa: Bár a Windows elmebeteg Flash installere nem engedi, de Linuxon úgy tudom frissíteni a Flasht, hogy utána az opera:plugins oldalon nyomok egy "Reload"-ot és hipp-hopp, lecserélődött. Erre csak az Opera képes. Sem a Firefox, sem a Chrome (bár utóbbi peppert használ, de akkor is égő, hogy az FF szintjén van ezen a téren).
És ez ráadásul még nem is programkomponens, hanem egy nyamvadt külső fájl. Miért is kell lock-olni? Mert más logikus magyarázat nincs rá, hogy miért nem tudja futás közben ellenőrizni, hogy van-e vagy nincs.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ezek csak arra jók, hogy szépen kényelmetlenné tegyél dolgokat, és valóban elkerülj mindenféle műveletet, ami pluszban írna vagy olvasna az SSD-ről, de akkor meg minek vettél SSD-t. Mire a jelenlegi SSD-d elhasználódna, addigra egy vinyót is nagy valószínűséggel lecserélnél vagy update-elnél, de mindenesetre addigra egy akkora kapacitású SSD jóval olcsóbb lesz, így az esetleges elhasználódása sem lesz már akkora probléma...
A leírás az angol UI alapján készült, mert lusta vagyok nyelvet váltani. A megoldás rém egyszerű: egy unpacked extensiont kell készíteni a saját szánk íze szerint, így a scriptek az O12-höz hasonlóan fájlban tanyáznak majd localStorage helyett, és a Tampermonkey-Stylish kiegészítők telepítésére nem lesz szükség.
Köszi. 
"
Ekkora csúszás? Szerinted ez megengedhető egy magát komolyan vevő cég számára? Nagyon nem, ez rengeteg hátrányt jelent, ami anyagiakban is jelentkezhet. (Gondolj akár egy pornós oldalra, számukra ez végzetes lehet. 
Új hozzászólás Aktív témák
Kérdés előtt olvasd el az
összefoglalót!
- AKCIÓ! - STEAM kulcsok /Anuchard, Aragami, Children of Morta, stb. - 2024.04.17.
- Eredeti Windows, telepítéssel! Digital Doctor Számítógép Szerviz
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
- Eladó Steam kulcsok kedvező áron!
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.