• Resolved tapiohuuhaa

    (@tapiohuuhaa)


    Foorumisivustoni tietokanta meni osittain rikki. Kaikki wp_posts taulun tiedot hävinneet.

    Löysin 1.4.2019 backup-tiedoston. JetBackup oli luonut sen. Tallensin viimeisimmän tiedoston. Yritin tuodan sen MySQL-ohjelmalla palvelimelle, mutta JetBackupin luoma SQL-tiedosto ei kelvannut phpMyAdmin-ohjelmalle. Se valitti:

    Incorrect format parameter

    Mikähän tässä on ongelmana? En JetBackupista löytänyt toimintoa, jolla tallenetun SQL-tiedoston saisi käyttöön.

    Joka tapauksessa mobiiliversio + tämän kuun keskustelut ovat meneet sen sileän tien, mutta olisi toiveissa saada aiemmat takaisin.

Esillä 8 vastausta, 1 - 8 (kaikkiaan 8)
  • Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    Tuon virheilmoituksen aiheutti lOCK – UNLOCK

    Mutta kaatumisen syy oli siinä, että CSS:ää oli liikaa. Ei kannata laittaa CSS:ää tietokantaan, jos kehittelee sivuja. Se tuhoaa lopulta tietokannan. Kannattaa laitaa @import… ja siirtää CSS FTP:llä paikoilleen.

    Näin siis ainakin silloin, kun testaa paljon asoita ja CSS:ää on paljon.

    CSS:n takia SQL-tiedostosta oli kasvanut 180MB suuruinen! Piti siivota kaikki CSS manuaalisesti pois.
    Mukana oli edellisen teeman roskiakin.
    Varoitus – CSS on vaaraksi tietokannalle!

    En saanut toimimaan. Tämä nyt on toivottavasti varoittava esimerkki muille.

    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    Tietokannan korruptoitumista estäisi, jos WordPress ei tallentaisi versioita. Onkohan hyvää version hallintaa. Jos sen sallisi tehdä vain korkeintaan kaksi versiota, risti hajoamiseen vähenisi todella paljon.

    WordPress oli oudosti laittanut tavallisen sivun perään CSS:ää, jolloin tavallinen tekstipätkäkin oli järjettömän kokoinen.

    Revisioiden määrää voi rajoittaa halutessaan, mutta tavaran määrä ei itsessään tietokantaa riko: MySQL-tietokannat on kyllä tehty kestämään paljon suurempia määriä sisältöä kuin mitä joku WordPress-sivusto tuottaa. Revisioiden määrän rajoittamille ei siis ole suuremmin syytä ja kyllä, ihan hyvää versionhallintaa on tallentaa jokainen muutos. Eipähän tarvitse arvuutella, onko juuri sillä kriittisellä hetkellä tallentunut uusi versio.

    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    Jostakin syystä nyt kuitenkin tietokanta rikkoutui ”Oma CSS” tallentamaani dataan. CSS:n koko läheteli alkuperäistä CSS:ää.
    Sen joka version tallentamista tietokanta ei kestänyt.
    180MB koosta varjaan yli 95% oli CSS-dataa.

    CSS on n. 140 Kb minimoitu CSS.

    Jostakin ihme syystä WordPress laittoi twentyfourteen-teeman CSS:ää tavallisen sivuun liittyneen tietueen yhteyteen.

    Jokainen tietue oli niin iso, että sen käsittely tietokoneellani oli erittäin hidasta. phpMyAdmin käsitteli yhtä tietutetta varsin kauan.

    Liian iso paketti kaatoi phpMyAdminin.

    Kun yritin palauttaa joitakin tiedostoja SQL-dumpista phpMyAdmin avulla, se pilkkoi yhden tietueen moneksi. Yhdestä tietueesta tuli yksi tavallinen sivu + 4-5 twentyfourteen-teeman tyylitiedostotallenetta. Poistin CSS-roskat.

    Sivustoa en saanut enää kunnolla toimimaan kun yritin kursia kokoon käyttökelpoiseksi katsomaani dataa phpMyAdmin avulla.

    Kaikki siirtyneet sivut eivät näkyneet missään. Kun hain tietoa yksittäisestä kentästä luodakseni siitä kopion, tuli ilmoitus että sivua ei voi julkaista. phpMyAdminista näki, että WordPress teki kaksi versiota heti kättelyssä. Toki se saattaa olla normaalia, mutta ilmoitus, että julkaisu epäonnistui, ei ole.

    foorumitietueet eivät löydä foorumiosastoja senkään jälkeen kun määritin, mihin osastoon mikin säie kuuluu. Mikään vastaus ei näy taustakäytössä.

    Visuaalinen editori ei toimi. Visuaalinen editori on muuten siitä herkkä tapaus, että jos on paha JavaScript tai CSS syntaksi virhe, se lopettaa toimintansa tai toimii vain osittain. Syynä se, että se lataa editorin yhteydessä CSS:ää ja JS:ää. Edeltävä rikkinäinen koodi tuohoaa toiminnan. Otin kaikki omat PHP-lisäykseni pois käytöstä. Tarkistin vielä CSS-paketit. Ei virheitä. Mutta editori ei toimi. Ei edes sen jälkeen kun otin CSS:t pois ja jäljelle jäi vain editorin itsensä lataama CSS.

    Jotain ihme häiritsevää roskaa tietueisiin siis jäi. Pitäisi kai vielä kerran luoda oma tietokanta ja tietue kerrallaan phpMyAdmin kentästä kopioida toisaalle. Tulee mukaan tosin vain teksi, ei tekstiin liittyvät avainsanat.

    Laitoin CSS:n erillistiedostoihin. Ongelmana on se, että ne tallentuvat turhankin helposti cacheen eivätkä aina päivity. Toinen ongelma on ::before/::after – merkistöä ei käydä lävitse, jolloin ä ja ö eivät näy oikein.
    tosin sen kai saa korjattua @charset -säännöllä, mutta mikä on oikea säätö, että ä jö näkyvät eikä niiden tilalle tule kysymysmerkkiä

    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    Muutin tuota. Laitoin tiedostot tietokantaan Code Snippet avulla.
    Sillä CSS tulee vain kertaalleen tietokantaan ja on helposti vaihdettavissa (koska minimoin CSS:n, sitä ei voi järkevästi korjata minimoituna). Ei ole ääkkösongelmaa. Pieni vaiva se, että alussa ja lopussa pitää olla hieman PHP-koodia. Ei ainakaan toistakertaa tule 170MB pelkkää CSS-dataa.

    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    Mediakirjasto ei näytä kuvia, koska viittaustiedostoja ei ole. Saisiko mediakirjaston jotenkuten palautettua?

    https://wordpress.org/plugins/wow-media-library-fix/

    ei auttanut

    • Tätä vastausta muokkasi 5 vuotta, 3 kuukautta sitten tapiohuuhaa.
    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    https://wordpress.org/plugins/add-from-server/ auttoi ja sen avulla mediakirjaston sai kuntoon

    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    Korjattu riittävästi.

Esillä 8 vastausta, 1 - 8 (kaikkiaan 8)
  • The topic ‘Tietokanta hajosi – miten sen saa korjattua’ is closed to new replies.