Rossz irány volt a modul írás, de lett megoldás
Sajnos rossz irányba haladtam, de sikerült találnom egy megoldást a problémámra.
Találtam egy issue-t az ubercart.org-on, ami megoldotta a problémát (http://www.ubercart.org/issue/15097/conditionally_tax_products_based_tax...).
Ez a uc_vat modul egy kicsit átfejlesztve, így az uc_vat_with_taxonomy nevet kapta.
Lényege, hogy az ÁFA-t (taxes) taxonómia szótárhoz köthetem, így az adókulcsok felvétele, a taxonómia szótár és értékeinek felvétele után a termékeket egyedi ÁFA-hoz rendelhetem.
Extra beállítás ként érdemes az alábbi beállításokat még kipipálni (admin/store/settings/taxes/vat):
* Add "including VAT" to tax inclusive product prices.
* Show VAT amounts in the cart and at checkout.
* Show VAT amounts in separate columns at checkout.
Így az ÁFA látható lesz a termék oldalon + a megrendelésnél is.
Innen letölthető: http://www.ubercart.org/files/issues/uc_vat_with_taxonomy.tar.gz
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Azonkivul hogy elolvasod meg is ierted hogy ki mit ir neked?
Azonkivul hogy elolvasod meg is ierted hogy ki mit ir neked? Az elottem hozzaszolo is szepen megirta neked. Mi nem ertheto ezen? (Picit mar kezdem unni...)
Ugyerzed hogy akik a modulokat irjak azok azert csinaljak hogy osszedoncsek a szervert? Egyszer mar megirtam ha jol remlik hogy sok helyen elo sem jon a gond mert az oldalnak van napi par vag ypartiz latogatoja. Ott teljesen mindegy hogy egy oldal lekeres 1 vagy 200 mysql lekerdezes general. De ha van 2000 latogato akkor ott a 2000 (ketezer) vagy 200000 (ketszazezer) nemmindegy. Szorozzuk be ezt meg azzal hogy egy oszott tarhelyen van 5 ilyen oldal akkor meg meg nagyobb a kulonbseg.
Hazepites...? Nezd ugy hogy egy kutyahazhoz ugyerzem eleg amator tudasom van de emeleteshaznak mar nem merek nekifogni. Erre most meg jon az is hogy nem baj majd a cementet (pl. VPS) is majd en amatoren megcsinalom, meg azt sem veszek, minek az ...
Egy masik pelda, az utobbi idoben ketten is megkerestek innen a forumrol hogy dolgozzak be nekik, nagyvonalakban a valaszban a lenyeg az volt hogy nem erzem magam profinak hogy elvallajam ...Szoval tudni kell hol a hatar...
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Elolvastam és arra
Elolvastam és arra válaszoltam amit megértettem. Nem tudom, hogy az említett /blog-entry címen mennyi jelenik meg, mert azt sem tudom honnan lehet kiolvasni a mennyit. Mi mennyi és hol? Hozzáadott tartalmak típusa és jellege (erre már válaszoltam 1-el feljebb): Article típusú és szöveg + kép jellegű.
A ..\sites\all\themes\ helyen van Alphorn és omega könyvtár. Ez talán azt jelenti, hogy az omega is le lehet töltve?
Átváltottam a bartikra és ott is csak 4 cikk jelenik meg. Ahhoz, hogy a következő 3-at is láthassam, tovább kell lapozni.
Az én oldalamat nem tudom belinkelni mert localhoston van. Amit belinkeltem oldalt, az egy frissen telepített Alphorn II sminkes bemutató oldal. Pontosan ugyanolyan, mint az enyém, annyi különbséggel, hogy nálam van néhány új, (Article) létrehozott cik is és az alábbi beállítást módosítottam annak érdekében, hogy több oldal is megjelenjen:
A Megjelenítés / Rendszer / Webhely információk / Címlap / Tartalmak száma a címlapon értéke: 7
Alapértelmezett címlap: http://localhost/drupal/blog (<<--Ezt nem én állítottam be)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
8 látogatót APC nélkül osztott tárhelyen ki kéne tudni szolgálni
ezek tipikusan nagy méretű cache bejegyzések, melyek kezelése általában túlmutat a szokásos MySQL beállításokon shared hoszting esetén.
Na de szerintem a napi 8 látogatót osztott tárhelyen, APC nélkül is ki kellene tudni szolgálni. A szolgáltató által jelzett brutális erőforrás-igény, a query-k száma pedig nem indokolt szerintem még akkor sem, ha 100 modul van telepítve az oldalra, és ha ennek a látogatószámnak az ötszöröse lenne (még az is csak 40):
Látogatók száma naponta: 8
A tegnapi napon futtatott lekérdezések száma: 2.555.573
Az összes lekérdezéshez képest a szerveren: 13.52%
Szóval én inkább valami rendkívül bugos működésre gyanakodnék elsősorban, vagy valamelyik modul, vagy épp a korábban említett esetleges MySQL query cache bug, vagy valami más hibaforrás következtében. Mondjuk az is igaz, hogy ahogy Drupalban a cache-elés például a fordításoknál működik, az szerintem nagyon durván erőforrás-pazarló...
Nekem elég gyanús, amit a kérdező kolléga írt, hogy belehekkeltek a core-ba, hogy a userek adatait, bejelentkezését, regisztrációját, aktuális állapotát egy külső adatbázissal tudják szinkronizálni. Jó lenne tudni, mit műveltek a core kódjával...
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Érdemes megnézni a forrását
Érdemes megnézni a forrását ilyenkor a kódnak. Drupalban van egy olyan wrongpractice, hogy egy függvény paraméter többfajta módon is értelmezhető, valamint a PHP lazaságát kihasználva többfajta típus is lehet.
Ha egy számot (igazából nem tömböt, muhahah) adsz meg akkor Te egy path id-t, vagyis pid-et adtál meg. Ilyenkor az kerül törlésre.
De a path_save nem vizsgálja, hogy van-e már egy adott source/alias páros, így felvehetsz akárhányat. Ilyenkor, ha törlöd az egyikek(pid), akkor még nem törölted az álnevet.
Sőt, ugyan azzal a source-val lehet több alias is, így ha az egyiket törlöd, akkor a másik még megmarad.
Ezért lehetőséged van arra, hogy töröld egy adott source összes alias-át, vagy egy adott nyelv összes útvonal álnevét, vagy ... stb. A kérdés, hogy milyen értékeket adsz át. Sajnos csak egyenlőséget lehet vizsgálni, tehát nem lehet az összes 'akarmi*' kezdetű álnevet ezzel a fv-el törölni.
Nyolcasban picit tisztább a kép, hisz ott nincs trükközés, ott csak feltételeket adhatsz meg... (vagyis nem, de legalább a neve az, és nem értelmezik kétféleképpen... talán majd a kilencesben.)
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Azt nem véletlenül nem
Azt nem véletlenül nem érdemes úgy listázni. Biztonsági kockázatot jelent. Függ a tárhely szolgáltató szerverbeállításaitól is, meg a .htaccess fájloktól.
De gondolj bele, ha van benne 10-20 fájl az még átlátható, de ha több, akkor egyre kevésbé. 100 db -nál már kigúvad a felhasználó szeme mire megkeresi azt amire szüksége van.
Egyszerűbb verzió, de ez is jóval kevésbé hatékony annál amit ajánlottam ha készítesz egy oldal típust és egyenként felveszed rá hivatkozásként az állományaidat, majd menühöz kapcsolod az oldalt. Itt is írhatsz rövid leírást az adott fájlhoz. Van amikor elég is ennyi. Sok állománynál előbb-utóbb ez is átláthatatlan lesz.
Ha úgy csinálod ahogy írtam, akkor átlátható és bővíthető lesz. Mikor feltöltesz valamit azonnal bekerül a listába. Engedélyezhetsz feltöltést felhasználónak is. Olyan views listát készíthetsz amilyenre szükséged van, ha csak a fájlokra való hivatkozást akarsz látni, akkor csak a fájl mezőt listázod. Taxonomy -val kategorizálni tudod a feltöltéseidet. Ez azt jelenti, hogy ha valakinek csak X típusú állományokra van szüksége, akkor csak azokat listázza.
Hosszú távon nem mindig az az egyszerűbb, ami annak látszik.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Azt figyeltem meg, hogy
Azt figyeltem meg, hogy
– a belépési mezőben a főoldalon ha beírom a feltételezett eddigi jelszavam, (amivel az a baj, hogy nem tudok meggyőződni róla, hogy jó-e, mert nem lép be), akkor látszólag újratölti az oldalt, de nem ír ki semmilyen hibaüzenetet, a cím is marad a korábbi. Hiba nélkül megjelenik ismét a főoldal, csak az adminisztrációs felület nem jelenik meg. Ha tudatosan „rossz” jelszót vagy felhasználót írok, akkor megjelenik felül piros keretben a klasszikus üzenet: Ismeretlen felhasználó vagy hibás jelszó. Új jelszó igénylése
– ugyanezt teszem a /user címen, akkor „jó” felhasználó jelszópáros beírásakor ez az üzenet jelenik meg: „Hozzáférés megtagadva Nincs megfelelő jogosultság a lap megtekintéséhez.” Rontott jelszónál, ugyanazon a webcímen ismét ez: „Ismeretlen felhasználó vagy hibás jelszó. Új jelszó igénylése”
Gyanús, hogy mégis jól emlékszem én a jelszóra, csak valamilyen hozzáférési gondom lett. Talán akkor amikor az oldalt a módosított chmod-ú settings.php-vel frissítettem? De hogyan lehet ezt kiverni a fejéből- Az eredeti jogosultsági állapotot visszaállítottam, a ckeditor mappáját – amivel a helyzet rosszra fordultakor foglalatoskodtam– is átneveztem, hogy ne zavarjon be.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Végülis a barátságosabb
Végülis a barátságosabb verziót választottam leírom (magamnak későbbre) meg másnak ha kíváncsi rá. ;)
Szükséges modul: administration views
Nézet -> /admin/people haladó menüben a kapcsolatokhoz hozzáadtam a
"Felhasználó: Rendelések"-et. Figyelj oda hogy ne legyen bejelölve a "megkövetelt kapcsolat"
A mezőkhöz hozzáadtam a "(orders) Rendelés: Order total (Order total)"-t, így a felhasználók oldalon (admin/people) mutatja a rendeléseket is. (Hiányossága, hogy minden egyes rendelést, ez esetben nem segít a Query settings-ben a "különböző" bekattintása.
Ha nem szeretnénk bíbelődni vele akkor Filter criteria-nál adjuk hozzá a
(orders) Rendelés: Order total és az operátornál állítsuk be az Üres (NULL)-t. Ez esetben csak azokat listázza akik egyáltalán nem vásároltak, egy az egyben ki lehet törölni. (Azért az utolsó regisztrációkat érdemes átnézni elég bosszantó lehet ha egy valós vásárló beregisztrál és rögtön törlik a fiókját. ;)
A nagyja spam emaileket úgyis az idegen emailszolgáltató szűrésével tömegesen ki lett törölve, ez már csak a gyomlálgatás, a kisebb rendszerekről küldött mailekre...
+ ahonnan sok spam érkezett letiltottam a regisztrációját az User restrictions modul segítségével. Pl. %@mail.ru = a mail.ru szolgáltatóval többé nem lehet regisztrálni. :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Azért van osztott hosztingokban is jó.
Jó-jó, de azért a sok apró oldalnak kár lenne egyenként több tízezres díjjal rendelkező szolgáltatót/csomagot választani.
Ugyanakkor azokon az oldalakon, ahol, maximum egy üzenetküldő boxban kimerül az interakció, még a wordpress bőven is sok. (Azért hozzáteszem, hogy a wordpressben is ki lehet irtani a felesleges dolgokat.) Ott sokszor egyszerűbb egy mikroframework használata, amivel talán a leginkább megspórolhatók az erőforrások.
A drupal 8 viszont valóban a nagyobb, összetettebb oldalak számára lehet jó választás, de osztott tárhelyeken is jól működik (már ahol nem spórol ki a szolgáltató mindent alóla). Minimum PHP 7.1.x, 128MB memória 1GB (ez persze az oldalszámtól és az oldalakhoz feltöltött médiáktól függ -1GB esetén, már több száz lap is elfér), vagy nagyobb tárhey és az OPCache php modul bekapcsolása ajánlott. Persze ennél gyengébb feltételek mellett is elmegy és pár lapból álló oldal esetén ez a tárhely is túlzás, de a jó működéshez minimálisan kb. ennyi ajánlott.
A backdrop cms és a wordpress esetén ennél jóval kevesebb is elég. A drupal 9-re ki fog alakulni egy remélhetőleg jól összeválogatott mag, ami a 8-asban, még kialakulóban van. Értem ez alatt: a mag által biztosított szolgáltatások összességét.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Pakolászás
Szia,
sminkbe azt, amit csak a választott sminknél lesz elérhető funkció.
Az esetek többségében, hogy minek hova kell kerülnie, elég, ha egy olyan site esetét veszed alapul, ahol a felhasználók változtathatnák az oldal kinézetét.
Viszont, ha az adott funkciót (legyen mondjuk dropdown menü) idővel fel akarod használni máshol is - az adott sminktől teljesen függetlenül -, akkor modul legyen.
Néha könnyebb egy modul-smink szimbiózist sminkben lekezelni, mint külön-külön, hogy univerzálisan minden körülmények között működjenek, de az ilyen fajta "lustaság" sokszor később bosszulja meg magát ;)
pl.: a dropdown menünél maradva: ha a saját smink "outputját" hozzáigazítod a menükezelődhöz (hogy egyszerűbb legyen megírni), akkor később írhatod újra ha más sminkkel is szeretnéd munkára bírni.
Ugyanakkor nekem van az egyik sminkemben egy pár soros php+jquery kódom, ami a hozzászólások moderátori linkjeit (felhasználói hsz-ok szerkesztése, törlése) különszedi a rendes linkektől (válasz, szerkesztés) és a hozzászóláson belül máshova pakolja egy dropdown menüben.
Ez csak pár sor, és teljesen smink-specifikus, bár modul-szerű funkcionalitása van, de szerintem ez inkább smink, mint modul. :)