szigetibalazs képe

Félreérthető voltam...
Szóval nem szó szerint 15-20 percenként kell a tartalmaknak létrejönniük, hanem egyszerre és az idő(dátum) mezőben szerepeljen 15-20 perc eltolással az idő.
Például így jönnének létre a node-ok:
Node1 - 2010.05.10. - 12:00
Node2 - 2010.05.10. - 12:20
Node3 - 2010.05.10. - 12:40
Node4 - 2010.05.10. - 13:00
Node5 - 2010.05.10. - 13:20
Node6 - 2010.05.10. - 13:40

A node repeat-tel szépen lehet generálni/klónozni a node-kat, csak éppen a percenkénti bontás már nem szerepel a beállítások oldalán, nekem meg arra lenne szükségem.

0
0
fecske95 képe

A .field-field-name osztálynak mit írjak be pontosan itt van a html kimenet ebből több mindennel próbálkoztam, de nem megy. Ha csak a .description állítom be tökéletesem megy de ugye az oldal összes filed description -ára érvényes.

<div class="form-item">
 <label>Jogi nyilatkozat: <span class="form-required" title="Szükséges mező.">*</span></label>
 <div class="form-radios"><div class="form-item" id="edit-field-jogi-nyilatkozat-value-igen-wrapper">
 
 <label class="option" for="edit-field-jogi-nyilatkozat-value-igen"><input type="radio" id="edit-field-jogi-nyilatkozat-value-igen" name="field_jogi_nyilatkozat[value]" value="igen"   class="form-radio" /> igen</label>
</div>
0
0
kismocsy képe

Én azt csináltam amikor ilyesmi kellett, hogy a tartalomtípus Súgó mezőjébe beleírtam, hogy
By sending this page you agree:
Licence pragraphs here...

Így nem kell pipálgatni. De ahol az a követemény ott a CKK/ Szöveg / Egyszerű be/ki jelölőnégyzetet alkalmaztam.

0
0
vacati képe

Gondolom a multisite-nál lassítja is a működést, hogy ugyanazok a file-ok szolgálnak ki adott esetben ugyan abban az időben indított lehívásokat. Mivel több honlap működik róla egy időben.

Tehát csak a core frissítésnél lehet előnye, ami nyilván egy nagy rendszer rendszergazdájának fontosabb, mint a gyors működés és diverzifikálás, amit megoldhat egy jó backup rendszerrel.

Miért van multisite a két nyelvű blogodra? Az nem úgy megy, hogy egy tartalom két nyelven?
Mint ahogy a felületi fordításoknál?

Tehát ha multi, akkor
sites/default/files (ide megy minden, ami közös az összesben)
sites/files (ide mennek külön mappákba az egyéni modulok, sminkek és egyéb file-ok)

Ha pedig nem multi, akkor a files-t kivesszük a default-ból és közvetlenül a sites-ba tesszük.

Jól gondolom, vagy van ennél frappánsabb megoldás is?

Bár nem szorosan ide tartozik, de: tegnap áttettem a default/files mappát a sites/files helyre és nyilván nem voltak elérhetőek a korábbi tartalmak. Majd mindent átmásoltam ebbe az új file mappába, de akkor sem találta, pedig a File rendszer beállításnál megadtam az új útvonalat.

Talán az adatbázisban vannak az egyedi útvonal megadások és azért?

Ha így van, akkor a manuális buherálás helyett van már kialakult, gyors megoldás az ilyen esetre, vagy egyszerűen ne változtassunk file rendszert már működő oldalon?

Pedig néha jó lenne.

A .htaccess filet is néztem, de abban nem volt semmi, ami ezt befolyásolhatta volna.

0
0
haripeti képe

Köszönöm a segítséget, úgy néz ki, megoldódott a nagy része, leírom, mi volt a gond, hátha valaki belefut hasonlóba:

1.
2. Volt full html (csak az), és az a CKEditorhoz volt kapcsolva, ami nekem kivette az összes CSS-formázást. Egy sima új Webform beviteli formával már nem kavart bele.
3. Ezt én bakiztam, amikor a form-mezőket duplikáltam, egy-két helyen csak a mező címét írtam át, a mező adatbázisba kerülő neve úgy maradt, ami duplikálást eredményezett, ez volt a baj (bár fura, hogy ezt egyáltalán engedi).
4. A karakterekkel kapcsolatban is igazad volt, a Helvetica furcsamód nem tetszett neki, mikor visszaraktam DejaVu Sans-ra, már oké volt.

Még egyszer köszi!

0
0
fecske95 képe

Nálam elég furcsán működik egyelőre. Ha a menük listája / szerkesztés -ben bepipáltam, hogy nyitott legyen minden menü aminek van almenüpontja Akkor nyitottan jelenik meg a menük oldalfrissítésnél.
HA meg nem pipáltam be, hogy nyitott legyen minden menü aminek van almenüpontja akkor kattintásra lenyílik de közben betölti az url-t ami a menühöz van rendelve + ugye lenyílnak az almenük.
Nálad hasonló működést produkál a DHTML menüjéhez? Vagy hogy van ez?

0
0
moha képe

Sajnos ismét előállt egy nagyon furcsa jelenség:

Bizonyos nyelvű oldalak lassúak. Devel szerint query-k csak kb. 250ms-et tesznek ki, ennek ellenére az oldal generálás ideje 12-13 másodperc
Az angol és német nyelvű oldalakon ez nem jelentkezik, ott normális a sebesség, csak a többi nyelven van gond.

- Ugyanezen a szerveren másik Drupal oldallal nincs baj.
- Más php tartalmak mennek rendesen
- Drupal cache ürítés ill. cache ki/be kapcsolás nem segít

Lehetséges, hogy a nagy terhelés miatt (angol és német oldalak kevésbé látogatottak, a magyar és lengyel (ami lassú) viszont most elég nagy látogatottságot kap) ilyen lassú az elérés? Mit lehet ezzel tenni?

Edit:
Meg van a baj: a temp könyvtárat teleszemetelte a Drupal, több százezer apró file volt benne, és mindben ehhez hasonló tartalom:

Drupal.locale = { 'pluralFormula': function($n) { return Number(($n!=1)); }, 'strings': 

És ezek után pár a felülethez tartozó szöveg, ill. annak fordítása.

Mi a fene ez és főleg miért pakolgatja ki őket fájlokba? Minden lapletöltéskor keletkezik belőlük vagy 20-30 db.

0
0
nevergone képe

Gondolom a multisite-nál lassítja is a működést, hogy ugyanazok a file-ok szolgálnak ki adott esetben ugyan abban az időben indított lehívásokat. Mivel több honlap működik róla egy időben.

Ki szolgál ki mit? Ne haragudj, de nem értem pontosan a logikát, amelyet követni próbálsz. Amúgy miért függne ettől bármi sebessége?

Bár nem szorosan ide tartozik, de: tegnap áttettem a default/files mappát a sites/files helyre és nyilván nem voltak elérhetőek a korábbi tartalmak. Majd mindent átmásoltam ebbe az új file mappába, de akkor sem találta, pedig a File rendszer beállításnál megadtam az új útvonalat.

Talán az adatbázisban vannak az egyedi útvonal megadások és azért?

Ez a beállítás visszamenőleg nem érvényes, csak az ezután feltöltött fájlokra. Az adatbázisod "files" táblájába less bele.

0
0
vacati képe

Üdv nevergone!

Arra gondoltam, amikor leírtam, hogy lassíthatja, hogy pl. van egy tárhely, amin van egy drupal. Többen felkeresik az oldalt és különféle dolgokat csinálnak. Ekkora a drupal mappa file-jait dolgoztatja. Ha ugyanez nem csak egy tárhelyet szolgál ki, hanem többet, akkor annyival több feladatot kell végrehajtania a kódnak.

Megnéztem a files táblát: világosan ott van minden elérési út. Kösz!
Tehát ha átteszem a files mappát, akkor ezeket kell átírnom egy sql paranccsal, és akkor nem kell egyenként. Az végül is nem olyan vészes. Majd kipróbálom, hogy akkor az új helyen minden rendben megy-e.

Szóval ti milyen mappastruktúrát használtok, mi a profi megoldás multisite és nem multisite esetén?

UI: Nem tudjátok megoldani, hogy csak a regisztráltak, vagy akár a fotóval rendelkezők láthassák itt a fotóinkat? Mert akkor feltenném magam én is.

0
0
nevergone képe

Arra gondoltam, amikor leírtam, hogy lassíthatja, hogy pl. van egy tárhely, amin van egy drupal. Többen felkeresik az oldalt és különféle dolgokat csinálnak. Ekkora a drupal mappa file-jait dolgoztatja. Ha ugyanez nem csak egy tárhelyet szolgál ki, hanem többet, akkor annyival több feladatot kell végrehajtania a kódnak.

Ez hibás elképzelés, a mai tartalomkezelő-rendszerek nem így működnek. Különösen, ha cache-ra gondolok, amikor lehetséges, hogy a kérések kiszolgálása a memóriából történik.

Szóval ti milyen mappastruktúrát használtok, mi a profi megoldás multisite és nem multisite esetén?

Nem multisite esetén azt, amit a Drupal alapból felkínál, multisite esetén pedig azt, ami itt le van írva. Vagyis sites/_oldalcíme_/modules és hasonlók.

Nem tudjátok megoldani, hogy csak a regisztráltak, vagy akár a fotóval rendelkezők láthassák itt a fotóinkat? Mert akkor feltenném magam én is.

Nem hiszem. hogy egy ilyen plusz terhelést rá kellene rakni még az oldalra, és az értelmét se látom. Ez nem holmi társkereső vagy Fabebook, ha vállalod az arcod, akkor töltesz fel képet, ha nem, akkor nem.

Ui.: Érdemes előbb megismerni a rendszert, elolvasni az elérhető dokumentációkat, majd alaposan kipróbálni mindent egy tesztoldalon.

0
0