Keresés

Részletes keresés

407fan Creative Commons License 2015.06.30 0 0 9862

Oké, beírtam, és ezt kaptam:

 

Parse error: parse error, unexpected '<' in C:PHPWEBtest.php on line 15

 

Mi lehet a baj?

 

Aműgy ez a teljes kód:

 

<!DOCTYPE html>
<html>
    <head>
        <meta charset="iso-8859-2" />
        <title>Doomino</title>
    </head>
    <body>
 
    <?php
       <img src="doomino.png" alt="Smiley face" height="42" width="42">
        
    ?>
     </body>
</html>

Előzmény: NevemTeve (9859)
NevemTeve Creative Commons License 2015.06.30 0 0 9861

Akkor tudnál szétnézni, amikor FTP-vel vagy ssh-val lépsz be... Végső esetben érdemes lehet elolvasni leírást is, amit a szolgáltató adott.

Előzmény: Laja73 (9860)
Laja73 Creative Commons License 2015.06.29 0 0 9860

Igen? Köszi! Hogy lehet public_html "fölé" hivatkozni? (ezen a szerveren /web)

$_SERVER['DOCUMENT_ROOT'] már ugye belül van.

Előzmény: NevemTeve (9857)
NevemTeve Creative Commons License 2015.06.29 0 0 9859
Előzmény: 407fan (9858)
407fan Creative Commons License 2015.06.29 0 0 9858

Üdv!

 

Nagyon alap segítséget kérnék, mint aki most ismerkedik a PHP- vel.

 

Hogyan tudok egy képet (pl. kismacskam.png) megjeleníteni? Esetleg pozícionálva?

 

Nagyon alap vagyok, nagyon érthető magyarázat kell.

 

(más nyelveken jobb vagyok, de ez itt konkrétan nekem nagyon új)

NevemTeve Creative Commons License 2015.06.29 0 0 9857

Tipikusan www-data (vagy  www) userként fut az Apache/PHP; te meg mondjuk laja73 userként tudsz belépni FTP-vel vagy ssh-val. Nagy valószínűséggel közös csoportotok sincs, tehát csak az 'other' jogosultsággal tudsz dologzni (vagy haladó esetben ACL-lel, de még nem tartasz ott).

 

Mondjuk nem volna rossz, ha ez a megosztott mappa az Apache látókörén (tipikusan a public_html könyvtáron) kívül lenne, biztos ami sicher.

Előzmény: Laja73 (9855)
Laja73 Creative Commons License 2015.06.29 0 0 9856

Na közben asszem megtaláltam a választ (egy oldalon, ami nem akart először bevezetni a Linux szépségeibe), eszerint a public. Azért megköszönöm, ha megerősíti valaki.

Előzmény: Laja73 (9855)
Laja73 Creative Commons License 2015.06.29 0 0 9855

Folder permissions ügyben otthon van valaki? Én ugyanis nem😃, ha azt szeretném, hogy az oldalamon (de csak azon) keresztül bárki, aki amúgy hozzáfér, fel tudjon tölteni egy adott mappába, akkor rá az owner, a group vagy a public vonatkozik?

halaloszto Creative Commons License 2015.06.29 0 0 9854

letöltesz a browserbe 5-10ezer sorokat és ott js-ből reszeled? hogy mik vannak! ez ma szokás?

Előzmény: hellsing (9850)
hellsing Creative Commons License 2015.06.29 0 0 9853

 

OK, így marad! Ez nem bug, hanem feature :-)

Előzmény: ervwrevwervwervewrv (9852)
ervwrevwervwervewrv Creative Commons License 2015.06.29 0 0 9852
Más nyelvekben nem tudom, hogy mi a szabály, magyarban az a-á, e-é stb. azonosnak számítanak rendezéskor.
https://hu.m.wikipedia.org/wiki/Magyar_%C3%A1b%C3%A9c%C3%A9
(bocs, nem tudom, hogy az index szoftvere hulladék vagy a mobilos Firefox, mindenesetre a javascript nem műxik, így tisztességes linket sem tudok beszúrni, a "tisztelt" supportnak nevezett izé meg tojik magasról az efféle hibajelzésekre)
Előzmény: hellsing (9851)
hellsing Creative Commons License 2015.06.29 0 0 9851

Felületes voltam: a unicode karakterek már nem a sor végén vannak, de nem is mind van jó helyen: az Á és az A, és az É az E-vel egyenértékűnek számolva, de pl. a Č jó helyen jelenik meg (a C után: a Ča… a Cr… után, a D előtt jön). Ha lenne erre valami javaslatotok, az jól jönne.

 

SELECT *, @rownum := @rownum+1 AS posSK FROM manufacturers cross join (select @rownum := 0) r ORDER BY manStat ASC, manNameSK COLLATE utf8_slovak_ci;

 

A manStat nem lehet a hiba oka, az csak egy enum: 'a' vagy 'i'.

Előzmény: hellsing (9850)
hellsing Creative Commons License 2015.06.29 0 0 9850

OFF:

 

OK, probléma leküzdve. Egy keveset utána olvastam és azt láttam, hogy js-ben a unicode rendezés hibás vagy nehezen járható, főleg nem 5-10e soros táblázatoknál. Úgyhogy a MySQL lekérdezésbe belevettem egy számlálót, php-val ebből HTML5 data-order attribútum készül, amire a dataTables vígan rendez.

 

:ON

Előzmény: hellsing (9849)
hellsing Creative Commons License 2015.06.28 0 0 9849

Collate: ez az! Bár nem működik*, de erről volt szó itt régebben.

 

A SHOW COLLATION eredményében van több szlovák is, pl. az utf8_slovak_ci (sajtóhiba volt), az utf8mb4..., stb.

 

*: a gond már nem a MySQL lekérdezés eredményében, hanem kliens oldalon a dataTables-ben van. Majd leküzdöm azt is.

 

Köszönöm!

Előzmény: ervwrevwervwervewrv (9848)
ervwrevwervwervewrv Creative Commons License 2015.06.28 0 0 9848

Addig is, míg esetleg előkerül valaki, akinek van benne gyakorlata:

 

"utf8-slovak-ci"? Az nem "utf8_slovak_ci" kellene, hogy legyen? (már feltéve, hogy nem sajtóhiba)

 

Ha az ORDER BY mezőnév mögé odaírsz egy olyat, hogy COLLATE utf8_slovak_ci, akkor sincs változás?

Egyáltalán: a szerver ismeri a szlovák karakterkészletet? Rohadt rég foglalkoztam mind mysql-lel, mind PHP-vel, de valami rémlik, hogy ezeket telepíteni kell...

Ha hozzáférsz egy mysql klienssel, akkor esetleg egy "SHOW COLLATION;" kimenetét nem ártana megnézni...

Előzmény: hellsing (9847)
hellsing Creative Commons License 2015.06.28 0 0 9847

Help! Tudom, hogy erről már volt itt szó, de most nem találom az akkori választ a MySQL UTF8 kérdésre.

 

Egy szlovák honlapon dolgozok (bár nem beszélek szlovákul). Minden 'utf8-slovak-ci'-re van állítva (a kapcsolat, a táblák és az egyes mezők is), ORDER BY esetén a Č, az É és hasonlók mégis az ascii-ABC után jönnek, ráadásul rossz sorrendben (pl. az É a Č elé — fordítva kéne).

 

Hogy is kell ezt rendbe tenni?

hellsing Creative Commons License 2015.06.16 0 0 9846

A jogosultságokat sajnos nem tudom korlátozni. A szolgáltató hüje ötlete, hogy előfizetésenként 1 adatbázis 1 felhasználóval, így az az egy a shop admin, a guest és a júzer is.

 

A tárolt funkció dolog tetszik, kipróbálom.

Előzmény: halaloszto (9845)
halaloszto Creative Commons License 2015.06.14 0 0 9845

a view semmi más, mint a select-ed letárolva. ha a view-ból queryzel, pont ugyanaz mintha az eredeti select-et adnád ki.

 

csinálj a forgalom táblára triggert, ami minden insert-re update-eli a termék táblát. ha jül értem a forgalom táblán nincs update/delete, ne is legyen.

 

nemtudom mennyire lehet tárolt eljárásokat csinálni mysqlben, csak lehet már. akkor írnék egy eljárást, ami az elad_termek(termekkod, mennyiseg, vevokod) . ezt hivna a UI, es ebben lekodolnek mindent amit csak kell. utanna le lehetne korlatozni a jogosultsagokat, hogy a UI kodnak ne is legyen joga a tablaba irni, csak olvasni meg futtatni az eladas eljarast.

 

Vajk

Előzmény: hellsing (9844)
hellsing Creative Commons License 2015.06.14 0 0 9844

A view-t (amit most használnék először) a készlet állandó számolására használnám (kb 2e féle termék, napi ~1e látogató, kb. 20-100 vevő). Azt se gyorsítja?

 

Egyszerűbb lenne, ha egy termék egy sor lenne és abból vonnám ki / adnám hozzá a kétirányú forgalmat, de szükség van statisztikai adatokra, úgyhogy marad ez.

 

És ha két táblát használnék? Az egyikbe menne minden (napi 20-100 insert és <10 lekérdezés), a másikban egy sor per termék (napi ~1000 lekérdezés + 20-100 update), és a webshop onnan szedné az adatot (nem kéne 1000× összesíteni), az admin stat része meg a részletes táblából?

Előzmény: halaloszto (9843)
halaloszto Creative Commons License 2015.06.13 0 0 9843

a view nem segit semmit. el kell mindenképp olvasnia az egészet hogy megtudja a készletet. zárást kell csinálni, és a sok sort a táblában lecserélni az egyenlegre.

 

Vajk

Előzmény: hellsing (9841)
hellsing Creative Commons License 2015.06.13 0 0 9842

...azaz az előző SQL az alap volt, ahogy a tiédet átírtam. Az igazi ez (ellenőrzéssel, hogy mire van stockLimit beállítva):

 

    SELECT
        s.prID,
        p.prNameSK,
        p.prStockLimit AS Stl,
        SUM(s.stVol) as Stk
    FROM
        stock AS s,

        products AS p
    WHERE
        p.prStockAlert='y' AND
        p.prStockLimit IS NOT NULL AND
        s.prID=p.prID
    GROUP BY
        s.prID
    HAVING
        Stk<Stl*1.1

Előzmény: hellsing (9841)
hellsing Creative Commons License 2015.06.13 0 0 9841

"ha jól értelek..."

Jól értesz :) Készletgazdálkodás és MySQL. Azokat a termékeket akarom kilistázni, amelyek a limit+10%-on belül vannak, hogy figyelmeztessen utánrendelésre.

A z adatmennyiségi problémára én is gondoltam. Az archiválás jó ötlet. Én első lépésként view-ba gondoltam tenni ezt a lekérdezést, azzal is gyorsítva a folyamatot. De van éves leltár, nincs akadálya az archiválásnak.

Nálam így működik:

SELECT p.prID, sum(s.stVol), p.prStockLimit
FROM products p, stock s
WHERE p.prID=s.prID
GROUP BY p.prID
HAVING SUM(s.stVol)<p.prStockLimit*1.1

Ha nincs a SELECTben a prStockLimit, nem megy a HAVING. Ez biztos valami eltérés a te SQL rendszeredtől.

 

Köszönöm a segítséget!

Előzmény: halaloszto (9840)
halaloszto Creative Commons License 2015.06.13 0 0 9840

ha jól értelek, a stock tábla a mozgást tartalmazza, fel kell szummázni product-ta hogy megkapd a nettó pillanatnyi készletet.

 

(nem ide tartozik, de ez súlyos skálázási problémához vezethet évek alatt, kell csinálni időszakos zárásokat ahol a mozgásokat leíró sorok elmennek valami archívumba, es helyettesítődnek egy nyitókészlet sorral)

 

az a problémád, hogy a feltétel a szummára kell vonatkozzon. amit írtál az először kiveszi az alacsony készletet(készletmozgást) leíró sorokat (főleg a negatívok lesznek azok, mert azok aztán igazán alacsonyak, és utánna szummáz.

 

gondolom ez valami mysql, olyan max 30 percet használtam, de gondolom abban is működik ez:

 

select p.prodid, sum(s.svol)

from product p, stock s

where p.prodid=s.prodid

group by p.prodid

having sum(s.vol)<p.alertlevel;

 

ha a having nem volt meg, nézz utánna a doksiban. a lényeg hogy a először szűr a where, utánna aggregál a groupby. ha az aggregálás eredményére kell szűrni, arra való a having.

 

Vajk

Előzmény: hellsing (9839)
hellsing Creative Commons License 2015.06.12 0 0 9839

'estét!

 

Azt hogy kell, hogy ha van egy products-táblám, benne stockLimit (riasztási limit, ha a termékből túl kevés van), és egy stock tábla, benne termékID és stockVol, ahol szerepel minden beszerzés és eladás, és szeretném lehúzni azoknak a termékeknek a listáját, amelyekből már kevesebb van, mint stockLimit+10%? Én így próbáltam:

 

    SELECT
        stock.prID,
        products.prStockLimit,
        SUM(stock.stVol) AS stVol
    FROM
        products,
        stock
    WHERE
        products.prID=stock.prID AND
        products.prStockAlert='y' AND
        stock.stVol<(prStockLimit*1.1)
    GROUP BY
        stock.prID

 

Ha a kék sor ott van, az stVol értéke mindig negatív, ha nincs, akkor a korrekt érték (a shop nem enged negatív készletet). Azon kívül, hogy valamit tutira rosszul írok, kéne egy kis magyarázat, hogy miért lesz negatív az stVol értéke, amikor nem is végzek rajta műveletet.

NevemTeve Creative Commons License 2015.06.09 0 0 9838

(kieg: ha minden komponens a helyi gépen van, akkor ssh kihagyható, cmd.exe elég;)

Előzmény: hellsing (9837)
hellsing Creative Commons License 2015.06.09 0 0 9837

Először nem értettem, hogy 0.2s miatt mit pöcsöljek az ssh-val, de 5.2-nél már dereng :)

 

Ennek a scriptnek igazából csak egyszer kell lefutnia (9 éves, működő webshop adatainak importálása egy új rendszerbe), csak azt nem értettem, hogy egy sima PC tényleg ilyen gyors lehet-e. És tényleg nem :)

Előzmény: NevemTeve (9834)
hellsing Creative Commons License 2015.06.09 0 0 9836

OK, egyből 5.2s körüli értékeket mutat. Mindjárt megnézem a doksit, hogy miért :)

Előzmény: ervwrevwervwervewrv (9835)
ervwrevwervwervewrv Creative Commons License 2015.06.09 0 0 9835

Szerintem a microtime-nak adj egy true paramétert is: microtime(true);

Enélkül elég érdekes eredményeket kaphatsz, ha megnézed a doksit ;)

 

Előzmény: hellsing (9833)
NevemTeve Creative Commons License 2015.06.09 0 0 9834

Az ilyesfajta műveletekhez ne használj böngészőt, ssh-vel lépjél be és a mysql saját eszközeivel vagy php-cli-vel csináld meg.

Előzmény: hellsing (9833)
hellsing Creative Commons License 2015.06.09 0 0 9833

'estét!

 

Ha lekérdezek egy táblázatot úgy, hogy megkapjam a nem-ASCII karaktereket tartalmazó sorokat:

 

SELECT prID, prNameSK FROM products WHERE prNameSK != CONVERT(prNameSK USING ASCII) ORDER BY prNameSK ASC;

 

ami kb. 10.000 sorból 3.600 találatot ad, a prName-ből minden spéci szlovák karaktert angolra cserélek az str_replace-szel (pl. č = c ), aztán ebből 3.600 MySQL UPDATE sor születik és el is végződik (sima mysqli query, nem multi):

 

UPDATE products SET prNameEN='" . $name . "' WHERE prID=" . $key;

 

és ennek az egésznek a végén kiderül, hogy ez 0.238475s - 0.280159s időtartamot vett igénybe (közben a prNameEN mindig kinullázva), akkor piszok gyors a gépem, vagy nem elég úgy sebességet mérni, hogy a script 2. sora a SESSION_START után az, hogy:

 

$time_start = microtime();

 

az utolsó 2 meg:

 

$time_end = microtime();
echo $time_end - $time_start . "s";

 

A gép tényleg gyors (Core i7-4820K 4.00GHz, 16GB RAM, SSD RAID 950MB/s olvasás, 850 írás), a böngészőablak 3-4mp-ig üres, pedig csak az időt kell megkapnia a "szervertől" (localhost) és egy üres képernyőre kiírnia.

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!