ibis képe

eredeti src:
http://vt500.neobase.hu/sites/vt500.neobase.hu/files/sites/www.vt500.neobase.hu/files/images/Dsc04462_0.thumbnail.jpg
aminek kellene lennie:
http://vt500.neobase.hu/sites/vt500.neobase.hu/files/images/Dsc04462_0.thumbnail.jpg
a képek elérési útjába belekerül egy felesleges sites/www.vt500.neobase.hu/files/ rész.
Ezt okozhatja hibás .htaccess rule (pl. ReWriteBase), hibás settings.php bejegyzés ($base_url) , hibás fájlrendszer könyvtár beállítás a http://vt500.neobase.hu/admin/settings/file-system vagy a http://vt500.neobase.hu/admin/settings/image oldalon, esetleg az image vagy egyéb fájl-feltöltő modulod hibája vagy hibás beállítása.

3
0
Sk8erPeter képe

Szerintem is az a célravezetőbb és rugalmasabb megoldás, ha minden galériába tartozó kép valójában egy elkülöníthető node.
Így a hozzátartozó leírás is könnyen testreszabható, és adott esetben egyéb fieldek is nyugodtan hozzáadhatóak. Ráadásul a Views-zal való manipulálás, adatmegjelenítés is nagyon leegyszerűsödik. Nem is beszélve a viselkedés saját vagy más modullal történő testreszabhatóságáról.

Szerk.:
szantog
2 perccel korábban küldted a hsz.-t, így a fentiek írása után látom csak, amit írtál, hogy D7-ben overkill. :) Akkor hogyan oldod meg a képek esetleges kiegészítését mondjuk egy plusz fielddel?
Arra gondolok, hogy mondjuk minden képhez kiválasztható, melyik szerző készítette, ezenkívül esetleg kell egy radio típusú field a feltöltésnél, hogy kiválaszthasd, hogy XYZ-ből mi igaz rá, egy checkbox pedig arra, hogy ABCDEFGH szempontok közül még melyik szempont(ok) vonatkoznak rá.
Ez most csak egy példa, a lehetőségek tárháza végtelen.

Szerk. 2.:
(23.39-kor írtra reagálva:)
már megint közel egyszerre írtunk. :D
Na, köszönöm, így már teljesen világos, akkor teljesen igazad van, hogy nyugodtan megoldható külön node-ok nélkül, mert ahogy írod, totál rugalmasan plusz fieldek adhatók hozzá így is amiatt, hogy a file is külön entitás, így fieldhozzáadogatós UI-t kapunk hozzá.
Na jó, akkor inkább asszem visszavonulok olvasgatni a Drupal 7 komoly újításairól.... A D6-ra alapozott tudásomat meg nem kicsit felül kell írnom új információkkal (vagy inkább hozzáfűzni).

0
0
Sk8erPeter képe

Na, ez jó, hogy megcsináltad, mert máris több infóval rendelkezünk.
Én arra tippelnék, hogy itt már nem a PHP-ben kell keresni a hibát, hanem a webszerverben. Érdemes lenne megnézni a webszerver logját is!

Most rá is kerestem, és ezt találtam, aminek a lényege pont az, hogy itt más szerint is webszerver problémája húzódik a háttérben:
http://serverfault.com/a/79745/79977
Ő linkelte ezt a cikket is, a kérdezőnél bevált, hátha nálad is be fog válni:
http://blog.bombcar.com/2008/01/apache-413-error-problems.html

Itt van még egy említésre méltó írás:
http://forum.joomla.org/viewtopic.php?p=2302244&sid=a654b905c1d75eb03aff...

Itt konkrétan a LimitRequestBody direktívára hivatkozik, aminek a feladata: "Restricts the total size of the HTTP request body sent from the client".

Csak próbálkozz! Aztán írj, milyen eredménnyel jártál, kíváncsi vagyok, jó-e valamelyik.
Pont rátaláltam egy ezzel kapcsolatos kérdésre Stack Overflow-n, itt is összefoglaltam ezeket: Request Entity Too Large.

0
0
aboros képe

a $submitted változódat a theme_node_submitted() függvény állítja elő. ezt megvalósíthatod a sminked template.php -jában és ezzel felülírhatod az eredeti függvényt.

<?php
function SMINKEDNEVE_node_submitted($node) {
  return t('Submitted on @datetime', 
    array( 
    '@datetime' => format_date($node->created),
  ));
}
?>

így nem lesz benne felhasználónév.
1
0

-
clear: both;

makgab képe

Ja igen... és a blokk nem látható az unregistered usereknek.
Pedig: "Csak a megadott szerepkörök tagjai láthassák a blokkot. Ha egy szerepkör sincs kiválasztva, akkor minden felhasználó láthatja a blokkot."
Tehát mindenkinek látnia kellene.

Miért nem látszódik mindenkinek? Ez is cache miatt lesz?

A teljesítmény menüben alapértelmezetten van minden:

Gyorstárazás:
[ ] Gyorsítótárazott oldalak a regisztráció nélküli felhasználók részére
[ ] Blokkok gyorstárazása 
Minimális gyorstár élettartam:
<nincs>
 
Gyorsítótárazott oldalak elévülése:
<nincs>
 
Sávszélesség-optimalizálás:
A külső erőforrások automatikusan optimalizálhatóak, ami a webhely felé irányuló kérések méretét és számát is csökkentheti.
[ ] CSS fájlok összegyűjtése és tömörítése.
[ ] JavaScript fájlok összegyűjtése.
0
0
Alexander képe

Letöltöttem a marketplace-t innen: www.drupal.org/project/commerce_marketplace
Localhoston próbáltam feltenni símán Drupalhoz, majd Commerce Kickstart-hoz is de az engedélyezésnél a köv.hibát jeleníti meg:

Notice: Undefined index: type in DatabaseSchema_mysql->processField() (line 205 of /opt/lampp/htdocs/commerce_K/includes/database/mysql/schema.inc).

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DEFAULT NULL, `created` DEFAULT NULL, `changed` DEFAULT NULL, PRIMARY KEY (' at line 5: CREATE TABLE {eck_commerce_store} ( `id` INT NOT NULL auto_increment COMMENT 'The primary identifier for a(n) commerce_store.', `type` VARCHAR(255) NOT NULL DEFAULT '' COMMENT 'The bundle of the entity', `title` VARCHAR(255) NOT NULL DEFAULT '' COMMENT 'Text', `uid` DEFAULT NULL, `created` DEFAULT NULL, `changed` DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE = InnoDB DEFAULT CHARACTER SET utf8 COMMENT 'The base table for a(n) commerce_store.'; Array ( ) in db_create_table() (line 2720 of /opt/lampp/htdocs/commerce_K/includes/database/database.inc).

Idáig még gond nélkül sikerült minden modult feltenni, működtek rendesen. Probáltam utána olvasgatni de nem jutottam semmire.
Mond ez a hiba valakinek valamit?

0
0
ecrazor1911 képe

A megoldás végül az "once" lett:

  1. [...]
  2. $("input[name='line_item_fields[field_1st_color][und]']").once().change(function(data) {
  3. [...]

A megoldásért sok-sok köszönet, pp-nek :-)

https://www.drupal.org/node/171213

1
0
Balu Ertl képe

Mi a legjobb megoldás?

Ahogy minden webhely különböző, nincs mindegyiknél legjobbnak nevezhető egyetlen tökéletes megoldás. Helyette azt javaslom, inkább a modulok népszerűségét nézd, mert az nagy valószínűséggel a te projektednél is megfelelő lehet.

Például a modulok Security kategóriájának tetején rögtön ezt a kettőt találod:
https://www.drupal.org/project/captcha
https://www.drupal.org/project/recaptcha
Sokan használjuk őket, jól működnek, várhatóan neked is megfelelnek majd, próbáld ki.

A Spam Protection kategóriában pedig régóta jól bevált a Honeypot. Mollommal már ne kezdj ismerkedni, jövőre le fogják állítani.

2
0
Illyés Edit képe

<?php
$nid = arg(1);
$parent_node = node_load($nid);
$category = $parent_node->field_category_id[0]['value'];
?>
[view:view_neve==<?php print $category; ?>]

A szűrők sorrendjénél fontos, hogy előbb legyen a PHP és utána az Insert View.

0
0
Robert Petras képe

Ez nekem most nagyon új amit írtál. Én ezt a leírást találtam a Drush dokumentáció oldalán a "pm-refresh" alias "rf" parancsról:

  1. pm-refresh
  2. Refresh update status information.
  3.  
  4. Aliases: rf

Ennyire benéztem volna, hogy ez a parancs a Features-t támogatja? A parancs leírása nagyon kurtafarkú, ebből én nem ezt következtettem. Nekem az jött le, hogy ez a parancs szimplán frissíti egy-egy modul frissítési állapotát. A Features modult abszolút nem ismerem még.

Szerintem "segi" egyszerűen csak felcserélte a betüket, de én sem vettem egészen eddig észre, mert tudtam, hogy mire gondolt (a pm-refresh parancs rövidítésére). Szóval nem nagy ügy.

0
0