[Vananematu]

Lihtne sisuhaldussüsteem.

MYSQL andmebaasist võetakse html kood ning kuvatakse tekstikastis. Seda saab muuta, ja uuesti andmebaasi teele saata, kuskohast see teise, kasutajate lehe poolt üles korjatakse ning otse HTML väljundiks veebilehele paisatakse.

Kõik on väga kena ja ilus, kui vaid haldusliideses vaene tellija HTML koodi mõistaks.

Ma ei oska isegi märksõnadega kirjutada, mida ma küsima peaks onu guugel käest.

Oskab keegi abistada?

Poolel teel võiks mõne sõnaga lausuda ka sellisest juhtumist, kus html vormis $_POST[] täidetakse ehk siis submit nuppu vajutatakse, kuid tekstikasti ei väljundata muudatust enne, kui suvalist linki lehe ulatuses vajutada ning tagasi pöörduda tekstikasti sektsiooni. Muudetavat veebilehte vaadates saab aru, et andmebaasis muudeti kohe kirje õigeks, kuid sisuhaldussüsteemi tekstikastis ei kuvata seda peale "Muuda"($_POST[]) vajutamist.

[Renka]

märksõna: fckeditor

[iceincube]

WYSIWYG editor (WhatYouSeeIsWhatYouGet)

Fck
tinyMc
rte editor
enda hetke lemmik nicEditor -> http://www.nicedit.com/

[mikk36]

http://geniisoft.com/showcase.nsf/WebEditors

[Speedee]

Kunagi kasutasin FCKeditor'i, nüüd olen jäänud TinyMCE peale. Peaks olema parim js WYSIWYG editor. Lihtne seada oma vajaduste järgi ja kui vaja saab ka modida. Dok on olemas ja foorumist saab ka abi.

[Vananematu]

Tänud kõigile variante pakkumast! Katsetan neist nii mõndagi.

Tegelikult küsiks lisaks, et kas PHP keelega ei olegi html väljundi kuvamine tekstikastis võimalik?

Ning endiselt ei ole mul aimu, miks peale submit nupu vajutamist (actioniks $_SERVER['PHP_SELF'] ei kajastu vastavas tekstikastis muudatused, vaid kuvatakse esmasel korral db-st saadud väärtused? Alles pärast menüüdes tuhnimist (refresh page) muudetakse ka tekstikasti sisu db-ga vastavaks.

Kolmas küsimus on mind samuti kummitanud - kuidas kasutaja viia ilma lingile klikkimast ühelt lehelt teisele? Näiteks juhul, kui koodis selgub mingi tõsiasi ning nüüd kuva kasutajale seda lehte..

[andrusny]

[Vananematu]

[andrusny]

Aga milles küsimus?

[inzinz]

Ee, defaultina peaks php ise väljastama headereid mis ütlevad et lehti ei cacheks browserid just sellesama põhjuse pärast et alati näeks uusimat seisu.
Ehk on praegu probleem selles järjekorras milles sa asju teed ? Kui ennem selectid baasist sisu välja ja siis alles paned baasi uue sisu (html'i) ning väljastad ikkagi ennem baasist päritud asja, siis näedki valet sisu.

Võibolla on näidata linki kus see probleem on ? Või seda koodijuppi kus see pärimise salvestamise ja kuvamise loogika on ?

Selline valesti infoga tegelemise järjekord on väga tihe põhjus sellistele asjadele.

[Vananematu]

Tänud andrusny. Su toodud võimalusi katsetan kindlasti. Javascriptiga pole tükk aega tegelenud, seega ei olegi nii agaralt selle poole vaadanud, kuid jah, seal avaneb uus maailm erinevate võimaluste osas.

inzinz, soovisid koodi näha? Ei tea kas leiad mingisuguse loogika järjekorra osas. Ma kopeerin siia vaid esimese teksti näitamise ning teksti muutmise loogika:

Spoiler

##1///////////////////////////////////////////////////////////////////////////////          ## Peamenyy linkide kuvatav tekst võetakse andmebaasist.          ## Menyy kirje valitakse vastavalt eelpool db-st saadud ning menyy_kirje[]          ## massiivi omistatud v44rtusest.          $p4ring_saa_andmed1="select tekst from mets_tekstid where kirje='$menyy_kirje[1]'";          $tulemus_saa1=$mysqli->query($p4ring_saa_andmed1);          $rida1=$tulemus_saa1->fetch_object();          $db_tekst1=$rida1->tekst;                    ## $db_tekst on vormi sees olev muutuja, millele omistatakse db-st saadud tekst.          ## $menyy_kirje_tekst on vormi sees olev muutuja, millele omistatakse db-st saadud tekst.          $db_tekst=$db_tekst1;          $menyy_kirje_tekst=$menyy_kirje[1];          $kast="tekstikast1";          require("materjal/lehed/muuda.php"); //html vorm                    ##1///////////////////////////////////////////////////////////////////////////////          ## Peamenyyl kuvatav tekst muudetakse tekstikastis (muuda.php)          ## kui muutuja POST ruum on seatud - submit vajutatud vormi väljal.          $sonum1=$_POST[$kast];          $p4ring_muuda1="update mets_tekstid set tekst='".$sonum1."' where kirje='$menyy_kirje[1]'";          if (isset($_POST[$kast])){             $tulemus_muuda1=$mysqli->query($p4ring_muuda1);             }

muuda.php fail:

<span id="algus_muutmine"><b><?php echo $menyy_kirje_tekst; ?></b> sisu muutmine:</span><br /> <form  method="post" action="<?php $_SERVER['PHP_SELF']; ?>"> <textarea id="txt_kast" name="<?php echo $kast; ?>" rows="2" cols="30"><?php echo $db_tekst; ?></textarea> <input type="submit" value="muuda" /> </form>

Ning mul on sama loogika baasil tekstikaste ühel lehel omajagu. Ehk siis vaid üks html vorm ühes failis ning php skript kasutab erinevatel etappidel ühte ja sama faili. Mul, kui php kirjutaja algajal, kulus selle süsteemi kokku panekuks omajagu aega, nii, et loogika vigu võib jätkuda küll.

See kood asub ütleme failis haldusmenyy_2_1. Sellel lehel on veel sessiooni kontrollimise osa ja muu nipet-näpet. Fail lastakse lehele switch kontrollstruktuuri kasutades ning require funktsiooni käivitades.

[inzinz]

Nagu ma arvasingi, sul on loogika valepidi, sul on ju hetkel nii:
select tekst baasist
kuva vorm
kontrolli kas teksti uuendati
salvesta baasi

Sa ei saagi ju sellise järjekorra juures oodata et kümme rida hiljem tehtud kontroll mõjutab kümme rida ennem väljastatud infot, see et sa tahad et muutuks ei tähenda et maagiliselt ise muutubki .

Õige järjekord oleks nii:
kontrolli kas on postitatud
uuenda baasi
vali tekst baasist
kuva vormi

[Vananematu]

Aitäh inzinz. Ma liht. mõtlesin, kuna PHP kood korraga serveri mällu laetakse, siis ei ole ka vahet kus üks või teine koodisektsioon paikneb. Tundub, et siiski on vahe Õnneks oli vahetus kerge, piisas vaid vormimuutuja ning "require" rea asukoha muutmistest.

Kas keegi oskab ehk paar sõna tähemärgitabelitest lausuda? MYSQL dokumentatsioon on igasugu keerulisi ja lihtsamaid tähemärgi muutmise funktsioone täis. Et kui tahta otse tekstikastist ladinatähestikule omaseid täpitähti sisestada, siis mis tingimused peavad olema täidetud?

Praegu olen jõudnud nii kaugele, et iga uue tabeli loomisel lisan sql süntaksi lõppu "character set latin7 collate latin7_estonian_cs." Pealtnäha justkui toimiks db-st täpitähtede kuvamine html-i ning vormist db-sse ülekandmine uuesti. Ilma vaikimisi character set'i muutmist ei kuvanud ta täpitähti üldse. Kuid MYSQL dok. näeb veel ette tähetabelite valmist db-ga ühenduse võtmisel, transportimisel ja ma ei tea veel millistes situatsioonides, et asi "õige" oleks.


Oskab keegi praktikaga kokkuminevat juttu selgitada, millistel minimaalsetel kriteeriumidel täpitähtede kuvamine igas serveris ja veebilehitsejas peaks toimima?

[mikk36]

1) Kasuta andmebaasis utf8 estonian'i
2) Andmebaasiga ühendumisel määra et tahad kasutada andmete ülekandmisel utf8't
Näide:

[inzinz]

Mina ise kasutan utf-8 charsetti estonian collationiga, ehk siis tabeli create on miskit sellist:

[mikk36]

Mis artiklist sa selle "deprecated" info võtsid ?
5.1 alt ei leia ma kuidagi sellist infot.

Edit: php dokis on sinu välja toodud funktsiooni juures kirjas märge

[inzinz]

No esiteks selle jooksutamise peale teeb php mysql klient vastavad asjad kõik enda siseselt ära, sealsamas php doki lehel on allpool ka näide kus keegi jooksutab päringut:
mysql_query("SET character_set_results = 'utf8', character_set_client = 'utf8', character_set_connection = 'utf8', character_set_database = 'utf8', character_set_server = 'utf8'", $conn);
kuna
"Neither SET character set 'utf8' or SET names 'utf8' worked properly"

Ja sealsamas on veel teisigi näiteid et "set names" ja "set character set" päringud ei anna soovitud tulemust kui samas mysql_set_charset töötab kenasti.
Kui mysql server on piisavalt uue versiooni peal ja php ka, siis igaljuhul on etem mysql_set_charset kasutada

EDIT:
Kogu selle utf8 asja juures tuleb meelde jätta et sa kõik erimärke sisaldavad failid salvestad utf8 kodeeringus (nii php, javascripti kui ka muud html failid).
Ning vahest on abiks ka see kui tekitad .htaccess faili kus sees on:
AddDefaultCharset UTF-8
Sellega apache ise ütleb enda poolt saadetavatele muudele html ja javascript failidele kaasa et nad on utf8 kodeeringus.

Esmapilgul tundub palju tööd, aga kui algus on korralikult tehtud, siis on endal hiljem kordades kergem

[Vananematu]

Tervist jällegi!

Üritan rohkem mysqli objektorienteeritud klassi kasutada, kus võimalik. Arvatavasti [ mysqli::set_charset ] meetod on võrdväärne [ mysql_set_charset() ] funktsiooniga.

mikk36, ma ei saanud aru sellest süntaksist :

[inzinz]

See header ei ole võrdväärne meta tagiga, meta tagi soovitan lisada küll, aga väga palju browsereid kasutab kodeeringu tuvastamisel headerist tulevat charseti infot, mitte aga lehe peal olevat infot, kuna lehe sisselugemiseks on juba charseti teadmine vajalik.
Kui on header pluss meta tag, siis peaks kõik browserid olema kaetud 100%.

Virtuaal koha pealt ei teagi, kui nad on sinu hostingu pakkujad, siis küsi neilt kas on mingi kindel põhjus miks nii vana php versiooni kasutavad kui 5.2.8 on juba väljas.

Kui php on 5.0.3 siis mysql_set_charset ei tööta kuna selles versioonis pole veel seda funktsiooni sees, seega on sul ainus võimalus jooksutada miku antud päringuid mysql_query('set names utf8'); jne ning loota et sellest piisab, mingitel juhtudel sellest aga ei piisa ja siis on pehmelt öeldes jama majas. Seega pöidlad pihku

[Vananematu]

Ohsa vana! Siin on nüüd korralikult kasulikku infi, mis te siia postitanud olete.

Nõndaks. Võtan kokku tähetabelite osa, parandage kui ma eksin:

1. PHP skriptis enne lehe laadimist:

[iceincube]

ma ei saa päris pihta mis katsetusi sa teed ja mida küsid, kuid,
nii salvestamisel kui näitamisel baasist peab juba olema mõlemal juhuls amad kodeeringud, et kindel olla.
Kui varem salvestatut hakkad välja kuvama siis vbla on jah katki midagi..

Ja otse faili kirjutatud tähed võivad olla katki kui sa pole salvestanud ka faili ennast utf8 formaadis. ( mis ditori kasutad- saad ikka valida kuskilt? )

[inzinz]

Üks point jäi sul läbi lugemata: sa pead ka omal kõik php html javascript jamuud failid salvestama utf-8 kodeeringuga!!!
Vali oma editoris save as, seal vaates peaks iga mõistlikum editor laskma valida ka charsetti (mis defaultib ascii peale tavaliselt ja sealt ka sinu täpitähe jamad kuna ascii täpitähe baite utf-8 kodeeringus ei eksisteeri ja browser kuvab mingit jama nende asemele).

Kui sul on kõik php html ja javascript failid utf-8 kodeeringus salvestatud, sinu php kood väljastab seda utf-8 headerit ning ka sinu baasi tabelid on utf-8 pluss teed seda "set names 'utf8'" siis peaks töötama kõik veatult, mul on igal pool kõik ok.

Seega veelkord: käi kõik failid üle, salvesta utf-8 charsetiga, lase ülesse, pane meta tagi uuesti utf-8 ja las php väljastab seda headerit. Kui valmis siis võid meile linki ka ehk näidata ?
Ja nagu iceincube ütles, varasemalt baasi salvestatud tekstiga võib olla probleeme, korrektselt kuvab ainult utf-8 charseti ajal salvestatud sisusid, seega edaspidi soojalt soovitan kogu see utf-8 asjandus saidi tegemise alguses ära teha, poole pealt charsette muutma hakata baasi tabeli väljade sisus on paras peavalu alati...

[Vananematu]

Mhmh. Nüüd sain veel targemaks. Ma arvan. et selles viga oligi. Miks te kohe ei öelnud, et editorid kõiges süüdi on Salvestamise osa libises silme eest mööda, mida eelnevalt kirjutasid inzinz

EditPlus2 kasutas standardina ANSI kodeerimist ja Crimson ASCII kodeerimist. Mõlemad editorid olid kasutuses ning jälg läks ka käest missugune editor milliseid faile puutunud oli. Ma näen nüüd, et asi on korras, kuna veebis sisestatud täpitähtede asemele ilmub andmebaasis vastavad html vasted, nagu ä on ä jne..

Lahe! Suured tänud kogu selle info eest. Lingini läheb aega, kuna töötan kohalikus võrgus andmebaasi ja php-ga. 5.0.3 serverisse ei ole veel jõudnud kolida arengujärgus lehte.

[mikk36]

[inzinz]

Testisin siin natuke neid set character set ja set names käske ja leidsin ka huvitava info: kui esmalt jooksutada set names utf8 ja peale seda alles set character set utf8, siis mingi totruse tõttu viskab connection_charseti tagasi defaulti peale, proovisin omal lokaalselt järgi ja tõepoolest:
peale set names oli character_set_connection ilusti utf8
peale set character set aga oli character_set_connection tagasi latin1

Kui aga teha järjekorras set character set utf8 ja siis set names utf8, siis oli kõik korras.
Arvatavasti sellest huvitavast käitumisest on ka tingitud kõik need veateated et vaatamata set names ja set character set kasutamisele ei saada asja tööle, põhjuseks siis see te reaalselt visatakse charset latin1 peale ja mysql seal teeb mingeid oma charset converte vahele.
Seega soovitan jälgida nende käskude järjekorda kuna nagu näha, vale järjekord keerab metsa seadistused...