DruTa képe

Végezetül, hátha el tudsz vonatkoztatni, én csak annyit mondtam, hogy... és ezt egy példán keresztül bemutatom:

Van egy node, amiben a felhasználó felvisz adatokat, és van egy tax mező, amiben hozzáadhat szótár elemet. Hirdetést visz fel, és almát akar eladni, de a legördülő menüben nincs alma. Ezért egy másik tax mezőben beírja, hogy alma.

A moderátornak ellenőriznie kell, hogy egyéb dolgokban nem írt-e be hülyeséget, ezért a hirdetés még nem jelenik meg.

És most jön amiről beszélek: jön egy másik felhasználó, aki almát keres. A keresőmezőben a szótárban keresi, hogy van-e alma. És van. Van, mivel bár nincs még közzétéve a hirdetés, de mivel ezt nem lehet szabályozni, az alma bekerült a szótárba.

Rákattint és azt látja, hogy nincs is ilyen hirdetés. Vagyis van, csak még nem aktív.

Nos, én ilyen esetre mondom, hogy ha be lehetne állítani, hogy a tax is csak a közzétételkor kerüljön a szótárba, akkor ez a hülye állapot nem jönne létre.

És itt tök lényegtelen, hogy az adatbázisban technikailag hogyan van, meg, hogy nem a node-hoz tartozik a tax, stb, stb., mindettől függetlenül logikus és szükségszerű lenne olyan beállítás, amiről beszélek. Ez egyáltalán nem lenne az általad leírtakkal ellentétben.

Többet nem akarok már ehhez a témához hozzáfűzni.

0
0
aboros képe

de erre a konkrét felhasználói esetre van a user protect modul.
https://www.drupal.org/project/userprotect
ez még annyival is jobb, hogy valóban a user accountot védi, nem az edit formra ad 403 at, hanem mondjuk egy bulk operationsből se tudsz kitörölni egy protected usert, ha a protection szabály nem engedi. így pl egy user akinek van administer users joga, nem tudja elvenni más userek xy roleját a people admin oldalon se meg sehogy se. ha csak annyival véded a usert, hogy bizonyos feltételek esetén 403 -at dobsz az edit formjára, attól még lehet tucat más hely ahol usereket adminisztrálsz, ott is mindenhol gondoskodnod kéne róla, hogy hiába van katikának administer users joga, az igazgatóság roleba lévők emailcímeit ne bánthassa meg a rolejukat se. ésígytovább.

userportect modullal ezt szépen be lehet állítani.
uid1 - mindent csinálhat
admin role - uid1 kivételével mindenkinek mindenét szerkesztheti
HR osztály - admin role és uid1 kivételével mindenkinek mindenét szerkesztheti

vagy ilyesmi. és usereket egyesével is lehet dierkt védeni, meg egy egész rolet is. nagyon hasznos tud lenni szerintem.

1
0

-
clear: both;

tamoca képe

Sziasztok! Egy nemzetközi mozgalomnak hoznék létre egy oldalt. Azért Drupal alatt mert sok éve ezt használom és mert a nemzetközi mivolta miatt a többi nemzetben is lehet majd aki besegít a helyi laikusoknak akik a mozgalmat szakmailag viszik, de nem tudnák maguktól kezelni az oldalon a publikációkat tartalmakat stb.
Ez nagy előnye volt a Drupalnak a közösségek megléte sok országban. Most a D7- en meg tudom oldani a többnyelvűséget azonban fogalmam sincs, hogy mondjuk egy év múlva mikor át kellene tenni D9 re akkor a laptopom a Dunába hajítom és elmegyek kapálni, vagy meg lehet majd csinálni. A tartalomtípusokat külön nézetekkel rendszerezve jeleníteném meg és ráadásul több nyelvre fordítva tükrözve. Persze lenne ami marad az adott nemzet nyelvén és nem lesz fordítva. Tehát mondjuk van egy tartalom angolul és marad is úgy némelyek meg le lesznek fordítva 20 nyelvere, aztán lehet olaszul beküldenek az olaszok egy tartalmat amit meg nem fordít senki mert helyi dolog. Minden tartalomtípusnál igaz ez lehet helyi és lehet fordítandó.
Ez a D7 en meg a D8 on totál máshogy működne. A D6 ról se tudtam a többnyelvű oldalakt áthozni a D7 re , ugyanebbe nem akarok megint belefutni. Rálát valaki arra , hogy ebből a szempontból lehetséges -e majd átállni D7 ről D9-re?

0
0

tamoca

Balu Ertl képe

Szia, köszi, hogy jelezted. Ellenőriztem, a szóban forgó két sztring alapvetően helyesnek tűnik, azaz az angol eredetinek megfelelő értelmű a magyar fordítás.

A probléma tehát, hogy rosszul („összecsúszva”) jelennek meg, máshonnan ered valószínűleg. A D7 kódjában itt van használva, de ahogy nézem, itt a format_plural() metódus előírásszerűen van írva.

  • Nem használsz esetleg valamilyen kereséssel kapcsolatos modult (például az itt felsoroltak közül)?
  • Esetleg fusd át ezeket az issue-kat, hátha valamelyik a tiéddel kapcsolatos.
0
0
Joee képe

A sima éves tárhelye nem olcsó és ott nincs ssh, így alapból nem elérhető a composer sem. Azt nem találtam sehol, hogy a táhely-szolgáltatás mellé biztosítana ssh hozzáférést. Azt csak VPS-nél láttam.
A VPS tényleg olcsó lenne első ránézésre, de le van korlátozva. A 20 és 40 Gb-os SSD havi forgalomkorlátozása 1 Tb. A sávszélesség korlátja 100 Mb. Ez 40 és 50 ezer. Amelyikről én írtam ott egyáltalán nincs forgalomkorlátozás és a sávszélesség is a tízszerese (1 Tb). Így pedig nagyon meggondolandó, hogy egyáltalán érdemes-e? Amelyik 1 Tb a tarhely,eu-n az viszont 303 276 Ft/év-nél kezdődik. Igaz, hogy nagyobb a tárhely, de aki nem nem tudja kihasználni annak nem ér semmit. Ráadásul még ezért a pénzért is ott van a havi 10 Tb forgalomkorlátozás. Az már nevetséges, hogy még évi 610 ezerért sem oldja fel a korlátozást.
Azért korlátozott VPS-eket lehet ennél olcsóbban is találni.
Azért ebben a topicban nem érdemes ennyire belemenni a szerver árakba, mert az csak meg lett említve és a nyitó hozzászólás a frissítésről és a Composer használatáról szól, ami szerencsére megoldódottnak tűnik.
Szerintem a szerverszolgáltatók árainak és szolgáltatásainak megbeszéléséhez egy másik topicot kellene nyitni máshol!

0
0
Illyés Edit képe

Nincs időm végiggondolni, amit írsz, de elméletileg így működik:

  1. Létrehozod a taxonómia kifejezéseket: foruminfo, és 3 gyermek: gyik, kiemelt, modera.
  2. Megírod a cikkeket és beteszed őket a gyik, kiemelt, modera kifejezések alá.
  3. Készítesz egy view-t a foruminfo-nak, amivel felülírod a taxonomy/term/x oldalt, ami a foruminfo-hoz tartozik. Tehát a view url-je taxonomy/term/x, az argumentumoknál pedig megadod a taxonomy term id-t. Ha most elnavigálsz a taxonomy/term/x oldalra, akkor nem a szokásos taxonómia oldalt fogod látni, hanem a foruminfo nevű view-t (tegyél valamit a view fejlécébe, hogy egyértelműen lásd).
  4. Létrehozol egy menüpontot, ami a /foruminfo linkre mutat.
  5. Létrehozol egy url aliast, ami a taxonomy/term/x-t lecseréli foruminfo-ra. Ha most elnavigálsz a /foruminfo oldalra, akkor a fent létrehozott foruminfo nevű view-t látod.
  6. Létrehozod a 3 view-t a kifejezéseknek úgy, hogy az url így néz ki: foruminfo/gyik, foruminfo/kiemelt, foruminfo/modera. Provide menu as tab opció bepipálva, valamelyiket válaszd default-nak, a /foruminfo oldalon mindig az lesz felül.
  7. Ha most elnavigálsz a /foruminfo oldaladra, akkor ott lesz a 3 tab, legfelül a default-ként megadott tab.

Leírni sokkal hosszabb, mint megcsinálni.

De tény, hogy a Views használata nem triviális.

0
0
Robert Petras képe

@zionduc Köszönöm! Hála Neked már a térképen is jegyzik Magyarországot a Drupical eseménygyűjtő oldalon.

Nagyon jó, hogy létrehoztad a Dug Gyor csoportot. Ha a közelben laknék biztos a tagja lennék és rendszeresen jelen lennék a találkozókon. Ahogy látom, mindig érdekes témák vannak a fókuszban és a pohár mellett.

Megkérdezhetem, hogy nagyjából hányan vagytok egy-egy ilyen összejövetelen? Amikor tavasszal felutaztam Budapestre egy Drupal találkozóra, kb. egy tucatnyian lehettünk.

Mostanában azon gondolkozom, hogy lenne-e elég érdeklődő Dunaújvárosban egy csoprt indításának vagy inkább a budapesti Drupal közösséghez csapódjak.

Köszönöm a tippet a Drupal Groups létrehozásával kapcsolatban. Egyébként az itt lévő szűrő nem sok segítséget nyújt abban, hogy pl. magyarországi Drupal közösségi/területi- vagy munkacsoportot találjak. Azt láttam, hogy a DUG Gyor még moderálásra vár, ezért lehet az hogy még nem jelent meg a publikus csoportok között és a szűrőben.

Létezik bejegyzett magyarországi DUG a győri csoporton kívül? Ha igen, akkor de jó lenne valahol itt a honlapon látni a linket!

Én is arra gondoltam különben, hogy legalább egy Drupal.hu adminnak kellene ezt létrehozni (a "nagy" magarországi csoportot) és nem egy új tagnak, de szívesen vennék részt mondjuk az események felvitelében és ügyintézésében ha gondoljátok.

0
0
Balu Ertl képe

Szia!

  1. Mivel a Drupal settings fájljai összefűzhetőek (azaz a sima settings.php a legvégén behivatkozza a settings.local.php fájlt (ritkább esetekben akár több másikat is), ezért esetleg érdemes lehet ellenőrizni, hogy összességében véve ezt a láncolatot, a legvégén lefutó fájlban szerepel-e még valahol értékadás a $settings['update_free_access'] tömbelemnek?
  2. Ha ez egy éles webhely és biztosra szeretnél menni, akkor kipróbálhatod azt is, hogy az Állapotjelentés oldaltól függetlenül eléred-e a domenem.tld/update.php útvonalat? Ha 403-at kapsz, akkor az megnyugtató, de ha 200-at, akkor szólj, és gondolkodunk tovább mi lehet az oka.
1
0

Webcím álnevek, és aszerinti listázás

Anonymous képe

Sziasztok,

Azt szeretném megtudni, hogy milyen módon valósithato az meg, hogy a /node mellett egy /cikkek rész is legyen, melyben egy összefoglaló cikklistát lehet látni, valamint a cikkek/1, cikkek/2 .... a cikkeket egyesével jeleníti meg! Mivel kezdő drupalos vagyok ezért nemtom, hogy van e erre modul külön, vagy beépitve is található e a drupalban. A menüben csak egy cikkek link lenne, ami a ?q=cikkek-re mutat, és ez után a felhasználó az adott cikkre kattintva bejön neki a pl a cikkek/23 nevű oldal(cikk).
Köszi : niel

agregator modul nem frissíti a híreket

Anonymous képe

Sziasztok!
Az oldalamon van egy Hungarian Unix Portál és egy SG Hírmagazin agregátor box, amiket már hat napja nem tud frissíteni a drupal. Ha kézzel akarom a hírolvasó oldalon, akkor ezt írja:
Hungarian Unix Portal csatornán feldolgozási hiba: (. sor)
Ja és a naplóban kiírja, hogy :
?ISO-8859-2? kódolás nem támogatott. Az iconv, GNU recode vagy a PHP mbstring kiterjesztés telepítése szükséges." Eddig viszont nem voltak ilyen gondjaim, mi lehet a probléma? Esetleg a legutóbbi frissítés miatt lenne?