Archívum
szeptember 24, 2016
Putenv PHP
Sziasztok!
Egy web template-t raktam fel egy ingyenes tárhelyre, és az installáció alatt ez a hibaüzenet fogadott:
Putenv PHP Extension Is Required
This PHP function is required. You'll need to enable it or ask your hosting provider to do it for you to continue the installation.
Tudna valaki segíteni hogy ez mi, vagy hogy mi ilyenkor a teendő?
Válaszotokat előre is köszönöm!
■ Egy web template-t raktam fel egy ingyenes tárhelyre, és az installáció alatt ez a hibaüzenet fogadott:
Putenv PHP Extension Is Required
This PHP function is required. You'll need to enable it or ask your hosting provider to do it for you to continue the installation.
Tudna valaki segíteni hogy ez mi, vagy hogy mi ilyenkor a teendő?
Válaszotokat előre is köszönöm!
szeptember 20
Weboldal XML-ben
Egy másik fórum témában felmerült, hogy a HTML + meta markup helyett XML-t és XSL-t kellene használni arra, hogy a weboldalainkat kiszolgáljuk. Erre példa Hídvégi Gábor kolléga saját oldala.
Az alapján, ami abból a threadből kiderült, ennek a megközelítésnek a következő előnyei vannak:
1. Minden adatot csak egyszer tárolunk el, nem duplikáljuk.
2. Nem alkalmazunk szerver oldali feldolgozást ahhoz, hogy a megfelelő kimeneti formátumra konvertáljuk az adatokat (HTML, RSS, stb). Ezzel CPU-t spórolunk meg.
3. Egységes, követhető adatformátumot kapunk, nincs szükségünk külön metaadatokra.
4. Mindig nyers adatokat küldünk, a klienstől dönti el, hogy mihez kezd vele.
Problémák, amiket én látok ezzel a megoldással:
1. Egyedi XML formátum oldalanként. Teljességgel kizárt, hogy mindenki hajlandó legyen ugyanazt az XML formátumot használni a hasonló adatai tárolására. Vagyis a közvetlen adat-integráció kizárt.
Ahhoz, hogy ez működjön, az XML formátumnak valamiféle közös jellemzőkkel kellene rendelkeznie, ami viszont azt is jelenti, hogy szükség lenne valamilyen schema.org-hoz hasonló markupra.
Ezzel viszont felmerül a probléma, hogy a piaci szereplők már most sem tudnak megegyezni róla, mert a Facebook az OpenGraph-ot nyomja, a Twitter a Twitter-flavor OpenGraph-ot, a Google pedig a schema.org-ot. Lásd még: XKCD.
Végeredményben tök mindegy, hogy HTML vagy XML, az adatainkat továbbra is markupolni fogjuk a mindenféle szolgáltató által támogatott sémák szerint, vagy az XML-ben közvetlenül, vagy az XSL átalakítás során.
2. Kliens oldali támogatás. Noha a böngészők XSL támogatása ma már egész tűrhető, sok adatfeldolgozó kliens nem rendelkezik ilyen képességekkel, és különböző okokból kifolyólag nem is fog. (pl.
Az alapján, ami abból a threadből kiderült, ennek a megközelítésnek a következő előnyei vannak:
1. Minden adatot csak egyszer tárolunk el, nem duplikáljuk.
2. Nem alkalmazunk szerver oldali feldolgozást ahhoz, hogy a megfelelő kimeneti formátumra konvertáljuk az adatokat (HTML, RSS, stb). Ezzel CPU-t spórolunk meg.
3. Egységes, követhető adatformátumot kapunk, nincs szükségünk külön metaadatokra.
4. Mindig nyers adatokat küldünk, a klienstől dönti el, hogy mihez kezd vele.
Problémák, amiket én látok ezzel a megoldással:
1. Egyedi XML formátum oldalanként. Teljességgel kizárt, hogy mindenki hajlandó legyen ugyanazt az XML formátumot használni a hasonló adatai tárolására. Vagyis a közvetlen adat-integráció kizárt.
Ahhoz, hogy ez működjön, az XML formátumnak valamiféle közös jellemzőkkel kellene rendelkeznie, ami viszont azt is jelenti, hogy szükség lenne valamilyen schema.org-hoz hasonló markupra.
Ezzel viszont felmerül a probléma, hogy a piaci szereplők már most sem tudnak megegyezni róla, mert a Facebook az OpenGraph-ot nyomja, a Twitter a Twitter-flavor OpenGraph-ot, a Google pedig a schema.org-ot. Lásd még: XKCD.
Végeredményben tök mindegy, hogy HTML vagy XML, az adatainkat továbbra is markupolni fogjuk a mindenféle szolgáltató által támogatott sémák szerint, vagy az XML-ben közvetlenül, vagy az XSL átalakítás során.
2. Kliens oldali támogatás. Noha a böngészők XSL támogatása ma már egész tűrhető, sok adatfeldolgozó kliens nem rendelkezik ilyen képességekkel, és különböző okokból kifolyólag nem is fog. (pl.
szeptember 20
Középre rendezés, auto width, fix szerkezet
Sziasztok,
Adott a következő struktúra:Azt szeretném elérni – a HTML struktúra változtatása és JavaScript hozzáadása nélkül –, hogy a listaelemek legyenek egymás alatt és a szélességük legyen auto (azaz a szélesség annak tartalmától függjön) és a listaelemek legyenek középre igazítva úgy, hogy a középre rendezést kizárólag a konténer text-align: center-e, befolyásolja, tehát a gyermekelemekben ezt már ne kelljen még egyszer megadni. Mindehhez pedig csak a .list és .item class-okat lehet felhasználni.
Lehetséges ez? Ha igen, hogyan? (Ha csak flex-szel kivitelezhető, annak is örülök már)
Ha nem megoldható a fent írt feltételekkel, akkor más fajta megoldásokkal ne fáradjatok.
■ Adott a következő struktúra:
<div class="container">
<ul class="list">
<li class="item">Item 1</li>
<li class="item">Item 2</li>
<li class="item">Item 3</li>
</ul>
</div>Lehetséges ez? Ha igen, hogyan? (Ha csak flex-szel kivitelezhető, annak is örülök már)
Ha nem megoldható a fent írt feltételekkel, akkor más fajta megoldásokkal ne fáradjatok.
szeptember 18
Információbiztonsági képzés
Sziasztok! Nagyon érdekel az információbiztonság, szeretnék ilyen vonalon tanulni. Tudtok esetleg olyan képzést ajánlani, amely nem kötött informatikus diplomához és el lehet vele helyezkedni? Köszönöm.
■ szeptember 17
non-www-ssl átirányítása www-ssl re
Üdv, van egy ssl tanúsítvány a www.domain.com domainemre, és nem tudom megoldani hogy a https://domain.com legyen átirányítva a https://www.domain.com -re anélkül, hogy SSL_ERROR_BAD_CERT_DOMAIN (A(z) domain.com érvénytelen biztonsági tanúsítványt használ. A tanúsítvány csak a következőre érvényes: www.domain.com) hibát ne kapnék.
Apache virtualhost configjában előrébb tettem ezt :mint ez vanSegítséget előre is köszönöm,
Elek
■ Apache virtualhost configjában előrébb tettem ezt :
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.domain\.com$ [NC]
RewriteRule ^(.*)$ https://www.domain.com$1 [R=301,L]
<IfModule mod_ssl.c>
SSLEngine on
SSLProtocol All -SSLv2 -SSLv3
SSLCertificateFile /var/www/clients/client1/web16/ssl/www.domain.com.crt
SSLCertificateKeyFile /var/www/clients/client1/web16/ssl/www.domain.com.key
SSLCACertificateFile /var/www/clients/client1/web16/ssl/www.domain.com.bundle
</IfModule>
Elek
szeptember 16
Tipewriter
Sziaztok,
Én is a kezdő amatőr webszerkesztők népes táborát gazdagítom így még nincs nagy tapasztalatom. Most egy saját oldal létrehozásán dolgozom.
Ahol most nagyon elakadtam, az egy Typewriter funkció Bootstrap alapkon.
Addig eljutottam, hogy már lefutattja a szövegkiírást, de sajnos nem látható módon. Én is csak a konzolon látom, hogy lefut a szkript és begépelteti a szöveget, de sajnos nem látszik az oldalon. :(
Van valakinek ötlete, hogy miért nem?
a webcím, ahol meg tudjátok tekinteni:
www.fluchtspiele.at
a felhasználónév:
Vill
a jelszó:
35dd963h
A segítségeteket előre is köszönöm,
Üdv:
Vill
■ Én is a kezdő amatőr webszerkesztők népes táborát gazdagítom így még nincs nagy tapasztalatom. Most egy saját oldal létrehozásán dolgozom.
Ahol most nagyon elakadtam, az egy Typewriter funkció Bootstrap alapkon.
Addig eljutottam, hogy már lefutattja a szövegkiírást, de sajnos nem látható módon. Én is csak a konzolon látom, hogy lefut a szkript és begépelteti a szöveget, de sajnos nem látszik az oldalon. :(
Van valakinek ötlete, hogy miért nem?
a webcím, ahol meg tudjátok tekinteni:
www.fluchtspiele.at
a felhasználónév:
Vill
a jelszó:
35dd963h
A segítségeteket előre is köszönöm,
Üdv:
Vill
htaccess.. de most visszafele :)
Kedves Fórumozók!
Segítséget az alábbi problémában remélek tőletek:
Volna nekünk egy kis rewrite szabályunk ami erőltetné a https használatát, amivel semmim gond nincs. Teszi a dolgát kb standart pár sor nem is térnék ki rá mert nem ezzel van a baj.
Úgy adódott, hogy az oldal egy bizonyos url-jén nem kéne hogy ezt ezt erőltesse mert ami onnan olvasni szeretne nem támogatja a https-t.
Szeretnék kérni tőletek egy olyan htaccess rule-t ami kivételt tesz az alábbi urlen:
http://www.domain.com/index.php?route=egy/ketto
viszont csak pontosan ezen
ezzel próbálkoztam:az egész így nézett ki:a végére még a www.-t is szeretnénk
mivel az utolsó sor akkor irányít https://www re ha nincs www gondolom én hogy ha amúgy is http://www-n hívom meg akkor már nem akarna rewriteolni az utolsó sor.
Előre is köszönöm
■ Segítséget az alábbi problémában remélek tőletek:
Volna nekünk egy kis rewrite szabályunk ami erőltetné a https használatát, amivel semmim gond nincs. Teszi a dolgát kb standart pár sor nem is térnék ki rá mert nem ezzel van a baj.
Úgy adódott, hogy az oldal egy bizonyos url-jén nem kéne hogy ezt ezt erőltesse mert ami onnan olvasni szeretne nem támogatja a https-t.
Szeretnék kérni tőletek egy olyan htaccess rule-t ami kivételt tesz az alábbi urlen:
http://www.domain.com/index.php?route=egy/ketto
viszont csak pontosan ezen
ezzel próbálkoztam:
RewriteCond %{REQUEST_URI} !^/index.php?route=egy/ketto
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/index.php?route=egy/ketto
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
mivel az utolsó sor akkor irányít https://www re ha nincs www gondolom én hogy ha amúgy is http://www-n hívom meg akkor már nem akarna rewriteolni az utolsó sor.
Előre is köszönöm
szeptember 14
htaccess hiba - nem szabványos 404 hibaoldal
Mi okozhatja, hogy ha a .htaccess fájlban beállítok egyedi 404-es hibaoldalt, akkor az jól megjelenik, viszont SEO teszterek (Woorank, Seoceros) azt írják, hogy nincs szabványos 404-es oldalam (500-as hibakódot jeleznek).
Alább látható a .htaccess fájlom tartalma. Ha eltávolítom a
RewriteRule ^([^/]+)$ /index.php?menu=$1 [NC,QSA,L]
sort a fájlból, akkor már szabványosnak jelzik a 404-es oldalt, csak nyilván nem tudok felhasználóbarát url-eket használni.
Elég elterjedt lehet a hiba, mivel az általam véletlenszerűen kipróbált oldalak nagy részénél jeleznek ilyen hibát a fenti validátorok.
Minden segítséget, ötletet előre is köszönök!
■ Alább látható a .htaccess fájlom tartalma. Ha eltávolítom a
RewriteRule ^([^/]+)$ /index.php?menu=$1 [NC,QSA,L]
sort a fájlból, akkor már szabványosnak jelzik a 404-es oldalt, csak nyilván nem tudok felhasználóbarát url-eket használni.
Elég elterjedt lehet a hiba, mivel az általam véletlenszerűen kipróbált oldalak nagy részénél jeleznek ilyen hibát a fenti validátorok.
Minden segítséget, ötletet előre is köszönök!
IndexIgnore *
ErrorDocument 404 /index.php?menu=404-error
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/]+)$ /index.php?menu=$1 [NC,QSA,L]
RewriteCond %{HTTP_HOST} ^www\.mysite\.hu [NC]
RewriteRule ^(.*)$ http://mysite.hu/$1 [L,R=301]
ErrorDocument 404 /index.php?menu=404-error
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/]+)$ /index.php?menu=$1 [NC,QSA,L]
RewriteCond %{HTTP_HOST} ^www\.mysite\.hu [NC]
RewriteRule ^(.*)$ http://mysite.hu/$1 [L,R=301]
szeptember 13
NativeScript – Cross-Platform Native Development with Javascript
Fejlesszünk natív mobilalkalmazást JavaScripttel
■ szeptember 12
PHP tömb használata másik php fájlból
Sziasztok!
Azt szeretném kérdezni, hogy, hogyan lehet elérni egy tömböt, két külön php fájlban?
Van egy fájlom, amiben létrehoztam egy tömböt, feltöltöttem, majd ezt szeretném használni egy másik php fájlban. Be-include-oltam a fájlt amiben a tömböt létrehoztam, de így nem jó.
■ Azt szeretném kérdezni, hogy, hogyan lehet elérni egy tömböt, két külön php fájlban?
Van egy fájlom, amiben létrehoztam egy tömböt, feltöltöttem, majd ezt szeretném használni egy másik php fájlban. Be-include-oltam a fájlt amiben a tömböt létrehoztam, de így nem jó.
