Új hozzászólás Aktív témák
-
pelyib
tag
válasz pigmeus #20250 üzenetére
Ha kifejezetten PHP akkor ide is johet, talan tobb valaszt is kapsz mint ha minden PMben tortenne.
Ha meg inkabb altalason OOP akkor az mehet ide: Programozás topic (kiemelt téma) -
#68216320
törölt tag
Sziasztok.
Tudnátok ajánlani olyan File listázó/letöltő programot (vagy csak osztályt) amit könnyen üzembe lehetne helyezni? Fontos lenne, hogy minimális vagy leginkább semmi JS és CSS legyen benne, mivel olyan eszközök számára a készülne, amiknél ez gondot okoz. ('80-'90)
Alapvetően majdnem megfelelő a normál apache/nginx könyvtárlista.A következő kritériumoknak kellene megfelenie:
- tetszőleges mélységű könyvtárlista (dir elöl, fájlok utána sorrend)
- ne direkt link legyen a fájlra, hanem mondjuk "download.php?dir=104&file=valami.ext" vagy valami ilyesmi
- adott fájl letöltésének számlálása (nem JS-el, mondjuk a fentebb említett download.php segítségével)
- könyvtárakat automatikusan térképezze fel, mivel nem web felületen lenne tartalom feltöltve
- több fájl/könyvtár kiválasztása esetén azokat 1db zip-ben töltse leEnnyi lenne.
Ismeretek esetleg ilyen kész rendszert? -
Agostino
addikt
sziasztok
hogyan kellene ezt a kérdést kezelnem szerintetek? adott egy loop, amiben szerepel egy mysql query. minden évhez hozzá van rendelve egy adatbázis mentés. ha a felhasználó azt mondja, őt a 2018 és a 2019-es mondjuk eladott almák száma érdekli, akkor 2018ben a loop a 2018-as adatbázishoz nyúl, 2019-ben a 2019-hez majd soronként kiírja a darabszámot.
viszont azt mondja a főnök, hogy rendben, de 2018ban az almákat eltérően számoltuk, és 2019-ben is máshogyan. tehát a loopnak figyelnie kellene az éves adatbázis váltást és a query váltást is. a kis kódom nagyon röviden valahogyan így néz ki:
if (loop éve 2018 majd 2019) {
ha dátum ez, használd ezt az adatbázist
2018.adatbazisa.query majd 2019.adatbazisa.query
echo eredmény }
[ Szerkesztve ]
hey friend listen, i know the world is scary right now but its gonna get way worse
-
sztanozs
veterán
válasz Agostino #20253 üzenetére
Célszerű az adatbázisban megírni azonos nevű view-kat úgy hogy már jól számoljanak és php-ból csak a különböző adatbázisokban levő view-kat query-zni.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Mike
veterán
tudtok natív PHP PDO megoldást JSON támogatásra? (olvasás, írás)
én nem igazán találtam
(Oracle Mysql-t használok, ahol van JSON mezőtípus) -
coco2
őstag
Sziasztok!
Egy php program összesen ennyi:
<?php
$xx= file_get_contents("https://wowcircle.net/en.html");
echo $xx;
?>Ha lefuttatom cli-vel, a válasz rá:
D:\>C:\wamp64\bin\php\php7.4.9\php.exe exec.txt
Warning: file_get_contents(https://wowcircle.net/en.html): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
in D:\exec.txt on line 2
D:\>Ha beírom a lapot böngészőbe, természetesen letölti. Ebben a tegyük működésképtelenné a webscrapereket játékban én még új vagyok. Hol van a kutyus elföldelve?
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
don_peter
senior tag
Hölgyek, Urak!
Az elmúlt napokban volt a szolgáltatómnál SQL és PHP verzió frissítés és emiatt néhány SQL lekérdezésem hibássá vált. Kérném a segítségeteket, hogy rendbe tudjam rakni a hibát.
A hibás kód az új verzióban:SELECT
*
FROM
(
SELECT
t.id,
t.title,
fu.datum,
u.nick
FROM
forum_uzenetek fu
LEFT JOIN topik t ON
fu.topik_id = t.id
LEFT JOIN users u ON
u.id = fu.user_id
ORDER BY
fu.datum
DESC
) AS a
GROUP BY
id
ORDER BY
datum
DESC LIMIT 10
Gondolom a táblák és mezők elnevezése érthető, t = topik, fu = fórum üzenetek és u = felhasználók.
Ez a kód a régi verzióban jól működött vagy is ki listázta a topikokat a topikba írt utolsó bejegyzésének dátumánál fogva csökkenő sorba rendezve. A csoportosítást pedig azért használtam, hogy egy topik csak egyszer szerepeljen a listában.Tehát ami kellene, hogy az utolsó bejegyzések dátuma alapján listázza ki a topikokat, fontos, hogy topik csak egyszer szerepelhet a listába.
Köszi előre is a segítséget.----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
coco2
őstag
-
-
don_peter
senior tag
Ezen a képen a régi állapot látható, és sajnos nem jól listáz, nem veszi figyelembe a bejegyzések dátumát. Pár nappal a frissítés előtt még jól listázott.
Ez pedig a módosított állapot, amikor már jól listáz.
Itt a szubselect-be egy plusz csoportosítást kellett elhelyeznem, így helyre állt a régi és jó listázási állapot.
Kérdés az, hogy lehet e ezt jobban és szebben megoldani?----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
sztanozs
veterán
válasz don_peter #20265 üzenetére
Amúgy szerintem:
SELECT
t.id,
t.title,
fu.datum,
u.nick
FROM
(SELECT
*
FROM
forum_uzenetek
GROUP BY
topik_id
HAVING
datum = max(datum) ) fu
LEFT JOIN topik t ON
fu.topik_id = t.id
LEFT JOIN users u ON
u.id = fu.user_id
ORDER BY
fu.datum DESC
LIMIT 10JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
válasz don_peter #20268 üzenetére
szerintem az volt a gond, hogy a fu és a f táblában is van datum mező. Eddig a fu.datum-ot vette fel, de szerintem most az f-datum-ot (de mivel nem látoma tábláidat így csak találgatok). Egyébkéntsikerült kipróbáűlni az átlalam javasoltat? ha belülre teszed a limitet (és biztos ami biztos kétszer rakod sorrendbe akkor sokkal olcsóbb a query):
SELECT
t.id,
t.title,
fu.datum,
u.nick
FROM
( SELECT
*
FROM
forum_uzenetek
GROUP BY
topik_id
HAVING
datum = max(datum)
ORDER BY
datum DESC
LIMIT 10) fu
LEFT JOIN topik t ON
fu.topik_id = t.id
LEFT JOIN users u ON
u.id = fu.user_id
ORDER BY
fu.datum DESCJOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
don_peter
senior tag
válasz sztanozs #20267 üzenetére
Sajnos az összeállított kódod hibás listát eredményez, de majd ha lesz kicsi időm átnézem, mert talán irányvonalnak nem rossz.ui: jelzem, hogy 2021-es dátummal is születtek bejegyzések, a helyes lista az előző bejegyzéseim egyikében szerepel kóddal és képpel illusztrálva..
Második kódod ugyan úgy hibás, első dátum 2019-03-16.
[ Szerkesztve ]
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
sztanozs
veterán
válasz don_peter #20270 üzenetére
Esetleg, ha tényleg MariaDB (ver 10.2+)SELECT * FROM
(
SELECT
t.id,
t.title,
fu.datum,
u.nick
RANK() OVER (PARTITION BY topik_id ORDER BY datum DESC) rank
FROM forum_uzenetek fu
LEFT JOIN topik t ON fu.topik_id = t.id
LEFT JOIN users u ON fu.user_id = u.id) temp
WHERE rank = 1
ORDER BY datum DESC
LIMIT 10Mostz látom mysql 5.7 -ott még nincs window function
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
don_peter
senior tag
"Az Önt kiszolgáló szerveren az éjszaka folyamán elvégeztük a kötelező mysql 5.6-ról 5.7-re való váltást, mivel a mysql 5.6 támogatása megszünt a cPanel hivatalosan minimum az 5.7-es verziót támogatja már csak."
Ezt a választ kaptam, hogy volt e valami kavarás a szervereken.----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
don_peter
senior tag
válasz sztanozs #20273 üzenetére
Ez pl. le sem fut.
Ahogyan Mike is említette, lehet hogy a subselect-el van gondja. Korábban is szívtam vele egy verzió frissítésnél, de sajnos egy komplexebb lekérdezésnél muszáj használnom. Vagy még bonyolultabb lekérdezéssel talán kerülhető lenne.
[ Szerkesztve ]
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
nevemfel
senior tag
válasz don_peter #20265 üzenetére
Itt valami szerveroldali query optimalizáció kavarhat be. Az egyetlen különbség, amit látok, az annyi, hogy a második lekérdezésnél, a belső query-ben szerepel egy GROUP BY fu.id, aminek önmagában nem látom értelmét, hiszen a fu.id egyedi azonosító minden üzenetre (már ha jó a sejtésem a táblaszerkezetet illetően).
A külső lekérdezésnél a GROUP BY id-nál nincs t. előtag, ami, talán, jóég tudja persze, de akár többféleképpen is értelmezhető a mysql által.
[ Szerkesztve ]
Rally against apathy draws small crowd
-
sztanozs
veterán
válasz don_peter #20274 üzenetére
Talán:
SELECT
t.id, t.title, fu.datum, u.nick
FROM
forum_uzenetek fu
INNER JOIN (
SELECT topik_id, MAX(datum) AS datum
FROM forum_uzenetek GROUP BY topik_id) max USING (topik_id, datum)
LEFT JOIN
topik t ON fu.topik_id = t.id
LEFT JOIN
users u ON fu.user_id = u.id
ORDER BY
datum DESC
LIMIT 10[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
don_peter
senior tag
válasz nevemfel #20276 üzenetére
Igen, tudom, hogy a belső csoportosításnak elvileg nincs sok értelme, de ezzel állt csak helyre a listázás. A többit már megbeszéltük a többiekkel és jeleztem, hogy minden megoldást végig próbáltam ami az aliaszokat illeti..
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
don_peter
senior tag
válasz sztanozs #20277 üzenetére
Ez működik és jól listáz.
Kérdésem az, hogy ez nem e bonyolultabb mint a dupla csoportosításos megoldásom?
Illetve kérnék egy magyarázatot az inner join () részhez, hogy teljesen tiszta legyen számomra mit is csinál az a rész. Nem alkalmaztam még ezt a csatolást. Köszi előre is a türelmed.----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
sztanozs
veterán
válasz don_peter #20279 üzenetére
Inner join leszűkíti a találatokat azokra (és csak azokra) az elemekre, amelyek egyeznek - tehát ahol a topik_id és dátum páros az, amit a belső selectben kitúrtál. IUgazából a te esetedben mindhol lehetne inner join-t használni, hiszen a biztos kell lenni egyezésnek userekre és topikokra is.
Amúgy nincs abban a táblában egy ID mező (ami szigorúan emelkedő)? akkor talán egy kicsivel még egyszerűbb (és gyorsabb) volna, és szerintem belülre is rakható a Limit, az is csökkentené a terhelést:SELECT
t.id, t.title, fu.datum, u.nick
FROM
forum_uzenetek fu
INNER JOIN (
SELECT
MAX(id) AS id
FROM
forum_uzenetek
GROUP BY
topik_id
ORDER BY
id DESC
LIMIT 10) m USING (id)
INNER JOIN
topik t ON fu.topik_id = t.id
INNER JOIN
users u ON fu.user_id = u.id
ORDER BY
datum DESC[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
don_peter
senior tag
-
coco2
őstag
.htaccess példák között kotorászok, és nem találok példát mappa tiltásra
Viszonylag egyszerű site szerkezet, gyökér könyvtárban hagynám az összes nyilvános cuccot, és a gyökérben lévő X mappába pakolnám az összes többit (tipikusan php-ban require_once-al behúzott php libek kerülnének külön). Akinek van ilyesmire htaccess példája, esetleg megkérném rá, koppantsa be, vagy örülnék bármi netes blog url-nek olyan példával.
Köszönöm
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
supercow
őstag
Nem lenne egyszerűbb a gyökérben bontani nyilvános és privát mappákra? Ahogy pl a Laravel csinálja Apache alatt, át kell állítani a DocumentRoot konfigot a public/ mappára. Hasonlót nem tudsz csinálni?
Ha mindenképp .htaccess kell, akkor a privát X mappában csinálsz egyet és abba beteszed eztOrder deny,Allow
Deny from all
Vagy google “htaccess deny current directory” az apache verzióddal.
[ Szerkesztve ]
In nomine Pasta, et Fusilli, et Spaghetti Sancti. Ramen.
-
coco2
őstag
válasz supercow #20284 üzenetére
Oké, a .htaccess per folder, ez benéztem, köszönöm a megoldást
A laravel trükkjét viszont nem ismerem. Nem értem az utalást a public/ mappára. Valami gyakorlati rávilágítás jól jönne.
Jelenleg ami van a virtual serverben, az "DocumentRoot /var/www/my-website". Oda terveztem berakni minden nyilvános cuccot egyben (összesen talán 30 file-ról beszélünk a kliens oldali .png grafikákkal együtt), és egy "/var/www/my-website/private" mappába a php libeket, meg a cron jobbal futtatott php cli-ket (talán 15 file fog oda kerülni összesen).
Milyen játékot lehetne játszani a mappákkal meg a document root-tal?
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
nevemfel
senior tag
A laravel trükkjét viszont nem ismerem. Nem értem az utalást a public/ mappára. Valami gyakorlati rávilágítás jól jönne.
Egyszerűbb a document_root-ot egy public almappára állítani, a publikus fájlokat pedig abba rakni, mint magára a teljes projekt könyvtárszerkezetére megadni, hogy aztán egyenként kelljen beállítani htaccessel a hozzáférési jogokat bizonyos fájlokhoz és folderekhez.
[ Szerkesztve ]
Rally against apathy draws small crowd
-
coco2
őstag
válasz sztanozs #20289 üzenetére
Csak hogy megnyugtassam magam, hirtelen rápróbáltam, hogy document root fölötti mappában létezett a "dead.letter" file, és hogy mit lép az apache-om a "www.mydomain.com/../dead.letter" -re. Visszaírta "www.mydomain.com/dead.letter" -re, pedig úgy emlékszem, nincs ilyen céllal rewrite rule-om. Ha működik is valami védelem, az alap beállítás lehet. Valós tud még lenni az a veszély a jelenkori világban?
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
sztanozs
veterán
Igen, de modern webszerverek esetében már csak a rosszul megírt modulokban, paraméterben átadva működik.
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
coco2
őstag
válasz sztanozs #20291 üzenetére
@sztanozs:
Köszönöm a figyelmeztetést. Egy spa / api szerver készül éppen, file hozzáféréseket nem tervezek paraméterbe rakni.
@nevemfel:
Köszönöm a tippet. Beállítottam normálisra az elérési jogokat, és most már működik, amit nem értettem. Illetve egy apróság még alant.
@supercow:
Elfogadom a gondolatot, és átszerkesztem a site-ot. Egyetlen nyitott kérdés maradt htaccess használatára, az pedig a bináris anyagok átlinkelése a stie-ról, ami kvázi sávszélesség támadása. Még nézem, hogy azt a rewrite rule-t berakhatom-e a virtual server beállítások közé, vagy annak viszont tényleg htaccess-be kell kerülnie. Ilyesmi:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?mydomain.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]
Más:
Egy index.php-ba ennyit raktam bele:
<?php var_dump(file_get_contents("index.php")); ?>
Ha valami html állományt linkelek be, vagy bármi mást, arra működik, szépen képernyőre dobja a tartalmát. Viszont ha php állományt, arra üres stringet kapok vissza - furcsa mód a string korrekt hosszúságával, de akkor is üres string.
A szerveren egyébként be van állítva script cache ezekkel:
"opcache.enable=1"
"opcache.memory_consumption=128"
"opcache.interned_strings_buffer=8"
"opcache.max_accelerated_files=1000"
"opcache.use_cwd=1"
"opcache.validate_timestamps=1"
"opcache.revalidate_freq=2"
"opcache.revalidate_path=0"
"opcache.max_file_size=0"
Az ember azt hinné, a php file-ok nem kerülnek blokkolás alá vagy olyasmi. Pláne, hogy kívülről text editorral bele tudok nyúlni akármelyikbe.Van valami kézenfekvő magyarázat a jelenségre?
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
coco2
őstag
Még egy apróság. Ha a DocumentRoot nem úgy kezdődik, hogy "/var/www/", egyszerűen csak nem szolgálja ki az apache valamiért. Hogy valami régi dolog, vagy új, nem tudom, sokáig nem követtem a verziók nyavajáit. Szükség megoldásként beraktam egy soft linket a www mappa alá, és arra mutat a document root. Bele éppen nem halok, de ha egyszerűen orvosolható a jelenség, egy tippet megköszönnék. Megkímélne +1 soft link-re figyeléstől.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
Taci
addikt
Sziasztok!
Remélem, tudtok ebben segíteni:
Adott egy időbélyegző, pl.:
$date = "Fri, 22 Jan 2021 17:36:10 +0100";
Hiába a 17:36 a pontos idő, az időzóna (+0100) miatt valamiért "elszámolja" magát, és 1 órával kevesebbet ír ki, pl.:
echo date('H:i', strtotime($date));
azt írja ki, hogy 16:36.Wordpress alatti Phpmyadmin amúgy, de Wordpress-ben is jó időzóna van beállítva (UTC+1), illetve Phpmyadmin is a pontos időt adja vissza a
SELECT NOW()
lekérdezésre.Oké, nyilván tudnám korrigálni úgy, hogy hozzáadok egy órát, de tudni szeretném vajon hol és miért megy félre a dolog, miért vonja le azt az 1 órát.
A forrás adott, tehát nem megoldás, hogy kiveszem belőle a " +0100" részt.
Köszi előre is.
-
pelyib
tag
The Unix timestamp that this function returns does not contain information about time zones. In order to do calculations with date/time information, you should use the more capable DateTimeImmutable.
[Forras]Hasznald inkabb a DateTime classokat. Tisztabb szarazabb erzes. (esetleg a Carbon nevu libet)
[Pelda]miért megy félre a dolog, miért vonja le azt az 1 órát.
Ha minden igaz (bar en kuka vagyok az time manipulaciohoz) a PHP UTC / GMT idozonat hasznalja. -
Taci
addikt
válasz pelyib #20296 üzenetére
Szia!
Köszönöm a választ!
Egyelőre az időzóna beállítása a leggyorsabb megoldás, amit a kódban írtál is, és szépen működik is (ahogy a példádban is):
date_default_timezone_set('Europe/Budapest');
Tesztelem, ha esetleg valami nem jól működne vele, akkor már megírtam a kód módosítását a
DateTimeImmutable
használatával is.Köszönöm!
-
coco2
őstag
Az időt epoch utc másodperc alapon célszerű tárolni, és csak a megjelenítéshez konvertálni olvasható stringes formára a helyi időzóna alapján. Mindenféle sql szerverek amik idő logikát támogatnak - kukás az összes támogatás. Maga az adattípus is. Bigint wins.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
coco2
őstag
válasz instantwater #20299 üzenetére
És gondolom fizetik is az extra szakember munkaórát szép pénzen
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
Új hozzászólás Aktív témák
- CAMPFIRE AUDIO ORBIT TWS In-ear fülhallgató wireless töltéssel (Qi) Bluetooth 5.2 AptX Adaptive
- HP Reverb G2 VR szemüveg eladó
- Macbook Air Retina 15" M3 - 8C CPU - 10C GPU - 8GB - 256 SSD - Magyar - Bontatlan
- Bányászgép / 9x 5700/5700 XT / 500MHs / ELADÓ!
- HP EliteBook 820 G1, G2, G3 - 12" notebookok - számla, 6 hó gar.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs