WWW-sivujen kännyversiolle käyttöliittymä

Mulla oli siihen yritys, jossa oli eri otseketiedot kuin alkuperäisessä ja tein mielestäni ohjeen mukaan. Katsomasi oli kopio alkuperäisestä. Muutin vielä kerran:
Koodi:
/*
Theme Name: Screenr Child Theme
Theme URI: https://www.famethemes.com/themes/screenr
Author: FameThemes
Author URI: https://www.famethemes.com
Description: Screenr Child Theme
Version: 1.2.3
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Template: screenr
Tested up to: 5.0
Requires PHP: 5.6
Tags: one-column, two-columns, left-sidebar, right-sidebar, custom-background, custom-colors, custom-header, custom-logo, editor-style, featured-image-header, featured-images, footer-widgets, full-width-template, rtl-language-support, sticky-post, theme-options, threaded-comments, translation-ready, blog, portfolio

This theme, like WordPress, is licensed under the GPL.
Use it to make something cool, have fun, and share what you've learned with others.

Screenr is based on Underscores http://underscores.me/, (C) 2016 Automattic, Inc.
Underscores is distributed under the terms of the GNU GPL v2 or later.

Normalizing styles have been helped along thanks to the fine work of
Nicolas Gallagher and Jonathan Neal http://necolas.github.com/normalize.css/
*/
Mutta sama tulos ts. lapsiteeman css:ää ei lueta. Asialla tosin on vain periaatteellista merkitystä.
Onhan sulla lapsiteeman functions.php:ssa
Koodi:
add_action('wp_enqueue_scripts', function() {
    wp_enqueue_style(
        'screenr-child',
        get_stylesheet_uri(),
        ['screenr-style'],
        wp_get_theme()->get('Version')
    );
});

ja lapsiteeman style.css headeriksi taitaa riittää:
Koodi:
/**
Theme Name: Screenr Child Theme
Version: 1.2.3
Template: screenr
*/
ei ole pakko noita kaikkia tietoja lisäillä.
 
Mulla on lapsiteeman functions.php lähes tyhjä, Siinä on vain muutama yksi globaali muuttuja ja vakio. + yksi oma funktio. Missään en mistään lukenut, että tuota add_action... pitäisi functions,php olla. Jos se on hyvä olla, sitten minulla on aukko WP:n tuntemuksessa. Osaan kyllä tehdä sille yhtä sun toista, mutta varmasti on pahojakin aukkoja, kun ei kaikkea dokumentaatiota tajua lukea.

Mutta ei. Tein esittämäsi muutokset, mutta edelleenkin teema itsepintaisesti kieltäytyy lukemasta lapsiteeman CSS-tiedostoa. Minulla ei ollut edellisen teeman kanssa esittämääsi koodia, mutta silti sen kanssa teema luki lapsiteeman CSS:n. Tämän teeman koodaajat ovat jotenkin "mustasukkaisia" omasta CSS:stään. No olkoon, ei ole iso työ ajaa se yli päityksen yhteydessä. Mitenkähän /screenr-child/assets/ -alaiset tiedostot toimivat. Lukeeko teema niitä lapsi-hakemistosta, vai pitääkö theme.js ja editor.css ajaa yli päivityksen jälkeen? Näistä theme.js on pakko olla muutettu. Editor.css siksi, että olen muuttanut värejä enkä halua editorissa nähdä väreillä, joita en käytä.

Functions.php on tyhjä kun tuntui, ettei oikein mikään pelaa sitä kautta. Esim. TinyMCE:n muutokset eivät pelanneet. Ajatuksena oli, että isommat CodeSnippet tietueissa olevat muutokset olisivat function.php tai sen alitiedostoissa inclule-avulla lisättynä. Mutta kun mikään lisäys ei oikein pelittänyt.
Lisäykset on CodeSnippet-tietueina, joista ne ainakin toimivat. Varmaan hieman hitaampi tapa mutta minkäs voit, jos homma ei muuten toimi.

Vai oliko toimimattomuuden syynä, että mainitsemasi skripti puuttui tiedoston alusta?

CodeSnippet on erittäin hyvä työkalu varsinkin testivaiheessa, sillä samasta koodista saa tehtyä eri verioita, joita voi nopeasti vaihtaa. Jos jokin menee pahasti pieleen, voi ottaa nopeasti käyttöön edellisen version. Siinä on kyllä erittäin vakavana puutteena se, että se ei osaa luettavasti tulkita sitä, onko jokin funktio käytettävissä vai ei.

Siltä saattaa mennä läpi koodi, joka kaataa edustan, koska funtio ei ole käytettävissä. Seurauksena on, että koodin tallennuksen jälkeen nettisivusto kaatuu välittömästi.

Toisaalta se saattaa valittaa, että funktiota ei ole määritetly, vaikka se on määritelty. Joskus on CodeSnippetin vuoksi pakko laittaa if(function_exists('funktion_nimi')), vaikka koodin suorittamisen kannalta se ei ole tarpeen. Se ei anna tallentaa toimivaa koodia ilman testiä.

Isommat ja varmasti valmiit koodipätkät olisi kyllä järkevä saada sijoitettua functions.php alaisuuteen. Jospa tuo lisäys auttaisi.

Kaikkein kivin piirre, josta olen maininnutkin on do_actions/add_actions-pari. Kun muuttaa mallinteita lapsihakemistoon, niillä voi tehdä melkein mitä vain. Tein joskus erään CMS:n kanssa töitä. Siinä jokainen muutos vaati ikävän raskaan koukkumäärittelyn. WP:n "koukut" on älyttömän paljon näppärämpiä.
Mallinteissa on yleensä valmiina aika lailla do_actions koukkuja, mutta niitä on helppo tehdä lisää. Olen mainninnut aiemminkin, että tein oman koukun footer-osan yläpuolelle. Siinä on mm. välittömästi footer-osan yläpuolelle sijoitettu leivänmurut. Välittömästi header-osan alapuolella oli valmiina koukku, mutta vastaava koukku puuttui footer-osalta, joten se piti lisätä.
 
Viimeksi muokattu:
Valikossa jäi harmittamaan, että se on 36px liian alhaalla. Testasin kirjautuneelle tarkotetun CSS:n kanssa. Kun määrittää z-index-arvot oikein, valikon sulkijan saa asettumaan valikon päälle. Näin nosto onnistuu. Kuten olen kertonut, tarkoituksella valikon ei pidä olla iha yläreunassa. Kun sain valikkoa nostettua, pitää miettiä uudestaan apuvalikoiden avaajien ulkoasu. Kun valikkoa nostetaan, ne nousevat valikon avaus/sulkupainikkeen tasalle. Mikä olisi paras apuvalikoiden avaajien ulkoasu. Ks. alla olevista kuvista vasemman puoleinen ja oikeanpuolimmaisin kuva. Keskellä kuva, kun apuvalikko on avattu.

Ulkoasu pitää muuttaa vastaamaan valikon avaus/sulkupainikkeen ulkoasua.

Korjasin nyt siis kirjautuneille. Haluan ulkoasukommentteja. Toimivuutta en siis aio muuttaa, mutta ulkoasukommenttien perusteella saatan muuttaa ulkoasua. Se punertava on teeman värejä ja näkyy korostuksena valikossa aktiivisen aihealueen kohdalla. Laitoin eri väriä ihan tahallisesti, että elementit huomataan. Pikavalinnoissa on kuvissa yksi kohta, joka on vain minulle.

Ongelmahan on siinä, että jos nostaa apuvalikoiden avaajat päävalikon rinnalle, kaiketi tyyli pitää vaihtaa päävalikon avaajan kaltaiseksi vai pitääkö? Vai saako jäädä tavallisen listakohdan kaltaiseksi? Jos muuttaa avaajien tyyliä, pitääkö kaikissa aukeavissa muuttaa tyyli?

Muutin valikoita myös niin, että avautuessaan peittää koko alueen eikä valikkojen yläpuolla näy sivua, jolloin vaikutelma on siistimpi.

PS. Kirjautuneena tulee hallintapaneeli ylös. Sen näkeminen aina ärsytti niin paljon, että poistin sen itseltäni näkyvistä koko ajan. Sen vaikutus asemointiin on n. 30px kaikilla kiinteästi määritellyillä valikkoon liittyvillä elementeillä.
 

Liitteet

  • 2021-05-16 09.59.11 www.sanaristikkofoorumi.net 3fcd40d402fb.png
    2021-05-16 09.59.11 www.sanaristikkofoorumi.net 3fcd40d402fb.png
    12,2 KB · Luettu: 34
  • 2021-05-16 10.14.30 www.sanaristikkofoorumi.net f5c43663fd56.png
    2021-05-16 10.14.30 www.sanaristikkofoorumi.net f5c43663fd56.png
    9,5 KB · Luettu: 31
  • 2021-05-16 17.28.49 www.sanaristikkofoorumi.net 6ad9d83501fe.png
    2021-05-16 17.28.49 www.sanaristikkofoorumi.net 6ad9d83501fe.png
    6,5 KB · Luettu: 19
Viimeksi muokattu:
Mulla on lapsiteeman functions.php lähes tyhjä, Siinä on vain muutama yksi globaali muuttuja ja vakio. + yksi oma funktio. Missään en mistään lukenut, että tuota add_action... pitäisi functions,php olla. Jos se on hyvä olla, sitten minulla on aukko WP:n tuntemuksessa. Osaan kyllä tehdä sille yhtä sun toista, mutta varmasti on pahojakin aukkoja, kun ei kaikkea dokumentaatiota tajua lukea.
Ainakin tällä hetkellä näyttää siltä, että joko functions.php on väärässä hakemistossa tai olet typottanut tiedostonimen.
https://www.sanaristikkofoorumi.net/wordpress/wp-content/themes/screenr-child/functions.php palauttaa 404 virheen.

Jotkin teemat saattavat ladata automaattisesti lapsiteeman css:n, mutta näyttäisi siltä, että screenr teema ei sitä tee, joten kyllä tuo lapsiteeman css:n sisällytys kuuluu lapsiteeman vastuulle ja edellä mainittu koodinpätkä pitää olla functions.php:ssa.
Dokumentaatio aiheesta löytyy täältä: Child Themes | Theme Developer Handbook | WordPress Developer Resources

Mitenkähän /screenr-child/assets/ -alaiset tiedostot toimivat. Lukeeko teema niitä lapsi-hakemistosta, vai pitääkö theme.js ja editor.css ajaa yli päivityksen jälkeen? Näistä theme.js on pakko olla muutettu. Editor.css siksi, että olen muuttanut värejä enkä halua editorissa nähdä väreillä, joita en käytä.
Screenr näyttäisi lataavan em. tiedostot näin:
Koodi:
wp_enqueue_script( 'screenr-theme', get_template_directory_uri() . '/assets/js/theme.js', array( 'jquery' ), '20120206', true );
add_editor_style( array( 'assets/css/editor-style.css', screenr_fonts_url() ) );
get_template_directory_uri() palauttaa isäteeman urin, joten et saa theme.js:ää korvattua suoraan sillä, että kopioit tiedoston vastaavaan paikkaan lapsiteemassa.
Mutta tämäkin ongelma on korjattavissa, kunhan saat functions.php:n oikeaan paikkaan.

Ensin kopioit isäteemasta theme.js:n vastaavaan hakemistoon lapsiteemassa ja sitten tälläinen koodinpätkä:
PHP:
add_action('wp_enqueue_scripts', function(){
    //isäteeman theme.js pois
    wp_deregister_script('screenr-theme');
    //oma tilalle
    wp_enqueue_script( 'screenr-theme', get_stylesheet_directory_uri() . '/assets/js/theme.js', array( 'jquery' ), '20120206', true );
}, 99);

Sensijaan tuo add_editor_style() lataa sekä lapsi- että isäteemasta vastaavan tiedostot. Eli lisäämällä css- tiedoston assets/css/editor-style.css lapsiteemaan, saat yliajettua isäteeman css:ää.

CodeSnippet on erittäin hyvä työkalu varsinkin testivaiheessa, sillä samasta koodista saa tehtyä eri verioita, joita voi nopeasti vaihtaa.
Ei, CodeSnippet ei ole missään vaiheessa hyvä työkalu :D
 
Tuota tuota, äärimmäisen nolo moka taas kerran. Olin laittanut vahingossa funtions.php - kirjoitusvirhe koodissa on kyllä hirveän iso moka. Eipä ollut ihme, ettei mikään toiminut.

No tein ohjeittesi mukaan. theme.js haetaan nyt lapsiteemasta. Tämä toimii juuri niin kuin kuvailit.

Ongelma paheni sen lapsiteeman suhteen esittämälläsi tavalla. Nyt selain latasi sekä /screenr/style.css että /screenr-child/style.css-tiedoston. Kahta ei pidä ladata. Jos ei saa ladattua vain lapsiteeman CSS-tiedostoa pitää aina yliajaa alkuperäinen.

Teit sen JS:n kohdalla niin, että poistit alkuperäisen käytöstä. Nyt pitäisi tehdä style.css:lle samoin. Ei kannata lisätä /screenr-child/style.css jos alkuperäistä ei saa pois käytöstä. Jos siis theme.js:lle on

Koodi:
wp_deregister_script('screenr-theme');

olisiko vastaava tyylititiedostolle seuraavaan tapaan:
Koodi:
wp_deregister_style('screenr-theme');

Edellinen teema luki automaattisesti ilman mukisematta child-hakemistossa olleen style.css-tiedoston ja latasi vain yhden style.css-tiedoston. Tämä teema temppuilee tässä asiassa pahemman kerran.

Olet kyllä varsin hyvä WordPress-osaaja ja tiedät asioita, joita itse en edes tullut ajatelleeksi.

Onpas sulla tiukka asenne CodeSnippetiin. Olet tainnut kokeilla? Oletko sinäkin kaatanut sivuston sillä kokeillessasi? Täytyy pala palalta siirtää CodeSnippet-tietueiden sisältöä functions.php alaisuuteen.
 
Viimeksi muokattu:
Teen nyt niin, että siirrän yksi kerrallaan CodeSnippet-tietueita functions.php-tiedostoon. Jos järjestelmä kaatuu tai jostakin syystä koodi ei toimi functions.php-tiedosta käsin, palautan edellisen version ja aktivoin CodeSnippet-tietuteen.

bbPressin koodille laitoin if(is_bbPress) {
}
Sitä on n. 45 kB, yhteensä omaa koodia lähemmäs 100kB. CSS:n käsittelytietueen jätän niin kauan kuin pitää kokeilla vaihtoehtoja.

Mutta kerropa, miksi CodeSnippet on sinusta huono?
 
Viimeksi muokattu:
Mutta kerropa, miksi CodeSnippet on sinusta huono?
Ensinnäkin tuo on täysin turha, tuo vain yhden ylimääräisen koodikerroksen mukaan ja tuo ei tee mitään mitä ei voisi suoraan (ali)teeman koodiin tehdä. Jos taidot ei riitä functions.php:n muokkaamiseen, niin parempi antaa olla. Lisäksi tuo tuo taas yhden tietoturvariskin mukanaan, suurin osa wp saittien murtamisista tehdään erilaisten reikäisten lisäosien kautta. Eikä suoritettavaa php- koodia pidä tietokantaan tallentaa. Edellisen johdosta koodin versionhallinta menee mahdottomaksi.
 
Tottahan tuo taitaa olla. Kuten kerroin, kaikki, mitä olin CodeSnippetin avulla laittanut, toimi kyllä functions.php:ssäkin.

Mutta kun CSS on vielä vähän hakusessa, sen kanssa voi nopeammin kokeilla. CSS:ään kun kaipaan ehtoja jo yksinkertaisesti siitä syystä, että tarvitaan eri CSS jos on kirjautunut ja ei ole kirjautunut.

Selkeimmin hoituu laittamalla PHP:llä if(!is_user_logged_in()){ tai if(is_user_logged_in()){

Ehkä poistan lisäosan käytöstä, kunhan CSS vakiintuu riittävästi. Tänäänkin tein vielä kokeiluja ja muutoksia, kuten #1003 tulee ilmi.

Tein muutaman jutun vain myös ihan itselleni, kuten kerroin aiemmin. Huomasit varmaan, että sen teeman style.css kanssa on edelleen ongelmia.

Käytin CodeSnippetiä nimen omaisesti versionhallintasyistä. Pystyi tekemään tietystä koodipätkästä eri versioita. Ehkä ne kaikki pitää heittää roskiin, kun kaikki on nyt CSS:n hallintaa lukuun ottamatta functions.php:ssä. Voisi sinne linkitykset tehdä ja jättää puhtaan kokeiluasteen koodin CodeSnippetille.

Mietin vielä, kumpikohan Dashicons-määrittelyistä on parempi. tarjoammalla vain woff2-fonttia tarjoitaan kyllä lähes kaikille selaimille toimiva fontti. Onko juuri enää selainta, joka ei sitä tukisi. Jos Internet Explorer, Edge, Fiferox, Chrome, Opera tai Safari suhteen käyttää selainta, joka ei sitä tue, on kyllä käytössä tietoturvallisuudeltaan arveluttava selain ja sellaiset saavat jäädäkin tukematta. En halua pätkääkään tukea kovin vanhentuneita selaimia. Ihan turhaa krääsää kysyä onko IE 9 tms.
 
Viimeksi muokattu:
Mutta kun CSS on vielä vähän hakusessa, sen kanssa voi nopeammin kokeilla. CSS:ään kun kaipaan ehtoja jo yksinkertaisesti siitä syystä, että tarvitaan eri CSS jos on kirjautunut ja ei ole kirjautunut.
Miksi ? Lähtökohtaisesti teet jotain väärin jos pitää css:ää muuttaa sen mukaan onko käyttäjä kirjautunut.

Tein muutaman jutun vain myös ihan itselleni, kuten kerroin aiemmin. Huomasit varmaan, että sen teeman style.css kanssa on edelleen ongelmia.
Huomasin, että jossain kohtaa lapsiteeman style.css oli käytössä,mutta nyt taas ei näytä olevan. Mikä ongelma tässä nyt on ?
 
CSS:ää pitää muuttaa kirjautumisen takia siksi, että WP lykkää sivun yläosaan mustan hirveän näköisen toimintopalkin. Sen lisäksi se lykkää paljon JS:ää.
Toimintopalkin takia pitää asemoida valikot n. 30px alemmaksi kuin jos ei ole kirjautunut. Sen saa näemmä myös pois kiusaamasta, jos ei halua käyttää. Mutta jos se tulee oletuksena kaikille kirjautuksena, sen olemassa olo tulee ottaa huomioon.

Valikkoa ei voi iskeä yhtään sen toimintopalkkihirvityksen päälle vaan sille pitää jättää toimintatila. Joissakin tilanteissa kyllä ärsyttävästi tila ei aina riitä kunnolla ja se lykkää osia valikon päälle. Hiivatin ärsyttävä tapaus, mutta sen kanssa nyt vaan pitää - välillä kiroillen - tulla toimeen.

Huomasin, että jossain kohtaa lapsiteeman style.css oli käytössä,mutta nyt taas ei näytä olevan. Mikä ongelma tässä nyt on ?

No kun teema latasi myös screenr/style.css -tiedoston. Jotta lapsiteeman css:n voi ladata, pitää saada pois käytöstä emoteeman style.css. Ajan mieluummin alkuperäisen yli kuin sen, että on sekä screenr/style.css että screenr-child/style.css.
 
Viimeksi muokattu:
CSS:ää pitää muuttaa kirjautumisen takia siksi, että WP lykkää sivun yläosaan mustan hirveän näköisen toimintopalkin. Sen lisäksi se lykkää paljon JS:ää.
Toimintopalkin takia pitää asemoida valikot n. 30px alemmaksi kuin jos ei ole kirjautunut.

Valikkoa ei voi iskeä yhtään sen toimintopalkkihirvityksen päälle vaan sille pitää jättää toimintatila. Joissakin tilanteissa kyllä ärsyttävästi tila ei aina riitä kunnolla ja se lykkää osia valikon päälle. Hiivatin ärsyttävä tapaus, mutta sen kanssa nyt vaan pitää - välillä kiroillen - tulla toimeen.
Ei ole tarvetta tehdä mitään if else hässäkää tuon takia, wp pistää oletuksena body- tagiin css-classin logged-in jos käyttäjä on kirjautunut. Tämän avulla voit targetoida haluttua css koodia vain kirjautuneelle käyttäjälle. Tai jos tuo adminbar niin paljon häiritsee, ota se kokonaan pois:
PHP:
add_filter( 'show_admin_bar', '__return_false' );

No kun teema latasi myös screenr/style.css -tiedoston. Jotta lapsiteeman css:n voi ladata, pitää saada pois käytöstä emoteeman style.css. Ajan mieluummin alkuperäisen yli kuin sen, että on sekä screenr/style.css että screenr-child/style.css.
Ja 'oikea' tapahan on nimenomaan lisätä vain omaa css:ää lapsiteemaan ja vain se mitä tarivtaan. Ladatkoon emoteema oman css:nsä. Ei ole mitään järkeä kopioida emoteeman koko css:ää lapsiteemaan ja lähteä sitä muokkaamaan.
 
Jossain on varmaankin
Koodi:
overflow: hidden

Toimii nimittäin skrollaus, jos body:n laittaa
Koodi:
overflow: auto
 
body- tagiin css-classin logged-in jos käyttäjä on kirjautunut. Tämän avulla voit targetoida haluttua css koodia vain kirjautuneelle käyttäjälle.
tiedän tuon luokan, mutta if - elseif pystyn hallitsemaan asian paremmin. Asia pysyy paremmin hyppysissä.
Ja 'oikea' tapahan on nimenomaan lisätä vain omaa css:ää lapsiteemaan ja vain se mitä tarivtaan. Ladatkoon emoteema oman css:nsä. Ei ole mitään järkeä kopioida emoteeman koko css:ää lapsiteemaan ja lähteä sitä muokkaamaan.
No kun otin pois kymmeniä kilobittejä CSS-koodia. En halua määritellä päälle vaan merkittävältä osin uusiksi. Se, mitä teen, ei toimi pikku muutoksilla. Piti poistaa CSS:stä erityisesti se, että mobile-valikko koskee vain alle 1140px aluetta. Ei päälle laittamalla olisi tullut mitään. CSS-tiedoston kokoa vähensin 101kb 59kB poistamalla kaikkea sellaista CSS:ää, jota en katso tarvitsevani koskaan sekä pakkaamalla tiedoston. Minulla oli siis ihan oikea tarve muuttaa emon CSS-tiedostoa.

Mobile-menun rajauksen poiston ohella poistin esim. yhteydenottolomakkeen CSS, koska se oli tehty sellaista lisäosaa varten, jota olen kerran kokeillut, ja josta en pitänyt. Poistin myös gallerian CSS:n. Jos tarvitsen, otan sen käyttöön vain galleriasivulla, erillistiedostona. Kun kerran tohtorit valittivat turhasta CSS:stä, poistin sitä aika lailla.
 
Viimeksi muokattu:
No kun teema latasi myös screenr/style.css -tiedoston. Jotta lapsiteeman css:n voi ladata, pitää saada pois käytöstä emoteeman style.css. Ajan mieluummin alkuperäisen yli kuin sen, että on sekä screenr/style.css että screenr-child/style.css.
Jos nyt ihan väkisin haluat sen emoteeman style.css:n pois, niin kokele vaikka tälläistä wp_dequeue_style('screenr-style'); mutta en todellakaan suosittele tuota tekemään.
 
No kun otin pois kymmeniä kilobittejä CSS-koodia. En halua määritellä päälle vaan merkittävältä osin uusiksi. Se, mitä teen, ei toimi pikku muutoksilla. Piti poistaa CSS:stä erityisesti se, että mobile-valikko koskee vain alle 1140px aluetta. Ei päälle laittamalla olisi tullut mitään. CSS-tiedoston kokoa vähensin 101kb 59kB poistamalla kaikkea sellaista CSS:ää, jota en katso tarvitsevani koskaan sekä pakkaamalla tiedoston. Minulla oli siis ihan oikea tarve muuttaa emon CSS-tiedostoa.

Mobile-menun rajauksen poiston ohella poistin esim. yhteydenottolomakkeen CSS, koska se oli tehty sellaista lisäosaa varten, jota olen kerran kokeillut, ja josta en pitänyt. Poistin myös gallerian CSS:n. Jos tarvitsen, otan sen käyttöön vain galleriasivulla, erillistiedostona. Kun kerran tohtorit valittivat turhasta CSS:stä, poistin sitä aika lailla.
Ei se ylimääräinen css ketään tapa. Sivustosi suorituskykyongelmat olivat/ovat aivan muualla kuin css-koodissa. Ja näin toimimalla varmistat sen, että jos emoteemaan tulee yhtään laajempi päivitys joka edellyttää uutta css:ää, joudut taas kopioimaan emoteeman css:n kokonaisuudessaan ja tehdä siihen haluamasi muutokset uudelleen.

Äkkiseltään katsoen tuo emoteema latailee ainakin tälläisiä scriptejä ja css:ää.
PHP:
wp_enqueue_style( 'screenr-fonts', screenr_fonts_url(), array(), null );
wp_enqueue_style( 'font-awesome', get_template_directory_uri() . '/assets/css/font-awesome.min.css', false, '4.0.0' );
wp_enqueue_style( 'bootstrap', get_template_directory_uri() . '/assets/css/bootstrap.min.css', false, '4.0.0' );
wp_enqueue_style( 'screenr-style', get_template_directory_uri() . '/style.css' );
wp_enqueue_script( 'screenr-plugin', get_template_directory_uri() . '/assets/js/plugins.js', array( 'jquery' ), '4.0.0', true );
wp_enqueue_script( 'bootstrap', get_template_directory_uri() . '/assets/js/bootstrap.bundle.min.js', array(), '4.0.0', true );
wp_enqueue_script( 'screenr-gallery-masonry', get_template_directory_uri() . '/assets/js/isotope.pkgd.min.js', array(), $version, true );
wp_enqueue_script( 'screenr-gallery-justified', get_template_directory_uri() . '/assets/js/jquery.justifiedGallery.min.js', array(), $version, true );
wp_enqueue_script( 'screenr-gallery-carousel', get_template_directory_uri() . '/assets/js/owl.carousel.min.js', array(), $version, true );
wp_enqueue_script( 'screenr-gallery-masonry', get_template_directory_uri() . '/assets/js/isotope.pkgd.min.js', array(), $version, true );
wp_enqueue_script( 'screenr-gallery-justified', get_template_directory_uri() . '/assets/js/jquery.justifiedGallery.min.js', array(), $version, true );
wp_enqueue_script( 'screenr-gallery-carousel', get_template_directory_uri() . '/assets/js/owl.carousel.min.js', array(), $version, true );
wp_enqueue_style( 'screenr-gallery-lightgallery', get_template_directory_uri() . '/assets/css/lightgallery.css' );
wp_enqueue_script( 'screenr-theme', get_template_directory_uri() . '/assets/js/theme.js', array( 'jquery' ), '20120206', true );
wp_enqueue_script( 'comment-reply' );
wp_enqueue_style( 'screenr-woocommerce', get_template_directory_uri() . '/woocommerce.css' );
Kaikki nämä saat tarvittaessa pois wp_dequeue_style() ja wp_deregister_script() funktioilla.
 
Jos nyt ihan väkisin haluat sen emoteeman style.css:n pois, niin kokele vaikka tälläistä wp_dequeue_style('screenr-style'); mutta en todellakaan suosittele tuota tekemään.
Ei auttanut ainakaan seuraava koodi:
Koodi:
add_action('wp_enqueue_scripts', function() {
    wp_dequeue_style('screenr-style'); // tämänhän piti poistaa käytöstä teeman style.css
    wp_enqueue_style(
        'screenr-child',
        get_stylesheet_uri(),
        ['screenr-style'],
        wp_get_theme()->get('Version')
    );
});
Tein niin radikaaleja muutoksia, että emoteeman CSS saattaa häiritä toiminnallisuuksia. Haluan olla varma, että mikään ei sotke sitä, mihin pyrin. Olen toki tietoinen, että saatan päivityksissä menettää jotain, mutta se on vain epäolennaista CSS:ää, ei sen kummempaa. Jos jokin tuntuu toimivan hassusti, pitää tutkia päivityksen jälkeen, onko muutostarvetta.

Kiitti edellisen kohdan infosta. En haluaisi kuljettaa mukana sellaista, mitä en koskaan tarvitse tai tarvitsen vai jollakin tietyllä sivulla.

Gallery ja karusellin voisi poistaa ja ottaa käyttöön vain sivuilla, joilla niitä tarvitsee.
 
Viimeksi muokattu:
Ihan mielenkiinnosta, minkälaisen muutoksen teit tämän johdosta alkuperäiseen css:ään ?
Poistin raja-arvon, joka määrittää missä kohtaa mobiilivalikkoa käytetään. Tämä on välttämätön pari sille, että poistin theme.js vastaavan raja-arvon ja ehdon, että mobiilivalikkoa tulee käyttää vain mobiilissa. Theme js:ssä piti poistaa käytöstä leveysalueeseen liittyvä mobiililaitetestaus, pelkkä raja-arvon muutos ei riittänyt. Piti tehdä radikaaleja muutoksia style.css ja theme.js tiedostoihin, että sai samantyyppisen valikon kaikille laitteille. Oli vaivan arvoista.
Lisäsithän tuon oikeaan paikkaan ja riittävän suurella prioriteetilla ?
Laitoin functions.php alkuun. Ks. #1019. Prioriteettia siinä ei ole. Taisit laittaa siinä theme.js kohdalla loppuun prioriteettiarvon. Jos sen lisää, saattaisi poisto toimia.
Enkös voi jossakin yksittäisellä sivulla gallerian ja karusellin aktivoida, jos haluan?
 
Laitoin functions.php alkuun. Ks. #1019. Prioriteettia siinä ei ole. Taisit laittaa siinä theme.js kohdalla loppuun prioriteettiarvon. Jos sen lisää, saattaisi poisto toimia.
Enkös voi jossakin yksittäisellä sivulla gallerian ja karusellin aktivoida, jos haluan?
Menee välillä tämä keskustelun seuraaminen haastavaksi kun ninjaeditoit noita vanhoja viestejäsi :D
Nuo dequeue ja deregister funktiokutsut on syytä pistää yli 10 prioriteetillä tapahtuviin actioneihin, sillä ethän voi poistaa sellaista mitä ei ole vielä lisätty. Emoteema tekee nuo lisäykset oletusprioriteetilla, joka on 10.
Toki voit tehdä nuo dequeuet ehdollisesti jollain tämänkaltaisella:
Koodi:
if(!sivulla_on_galleria()) {
   dequeue_galleria();
}
 
No onnistui lopulta
Koodi:
add_action('wp_enqueue_scripts', function() {
wp_dequeue_style('screenr-style');  
wp_dequeue_style( 'screenr-gallery-lightgallery');
wp_dequeue_style( 'screenr-woocommerce' );
},99);

...

// CSS- ja JS-tiedostot
add_action( 'wp_head', function () { ?>
<script src="/wordpress/wp-content/themes/screenr-child/forum.js?ver=1.2"></script>
<script src="/wordpress/wp-content/themes/screenr-child/forum-mobile.js?ver=1.7"></script>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr-child/style.css?ver=2.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr-child/colors_common.css?ver=2.0" />

Kiitti hirveesti. Luulin, että olen jotenkin teeman pakkkosyötön armoilla enkä voi poistaa itselleni tarpeetonta roinaa. Tuli kunnon "autotallin siivous":
Awesome-asennus on välttämätön, koska teema käyttää sitä paljon. Dashicons fronend-käytöstä voisi suurella vaivalla ehkä luopua, jos vastaavat ikonit löytyvät, mutta olisi kyllä niin työläs, ettei taida olla vaivan arvoin (0,01 sek/sivu jos sitäkään).
 
Tässä on skriptien ja CSS hallinta sivun alussa kokonaisuutena:
Koodi:
add_action('wp_enqueue_scripts', function() {
wp_dequeue_style('screenr-style');
wp_dequeue_style( 'screenr-gallery-lightgallery');
wp_dequeue_style( 'screenr-woocommerce' );
},99);

add_action('wp_enqueue_scripts', function(){
 
wp_deregister_script( 'screenr-gallery-masonry');
wp_deregister_script( 'screenr-gallery-justified');
wp_deregister_script( 'screenr-gallery-carousel' );
wp_deregister_script( 'screenr-gallery-masonry');
wp_deregister_script( 'screenr-gallery-justified');
wp_deregister_script( 'screenr-gallery-carousel');
    //isäteeman theme.js pois
    wp_deregister_script('screenr-theme');
    //oma tilalle
    wp_enqueue_script( 'screenr-theme', get_stylesheet_directory_uri() . '/assets/js/theme.js', array( 'jquery' ), '20120206', true );
}, 99);

// Omat CSS- ja JS-tiedostot
add_action( 'wp_head', function () { ?>
<script src="/wordpress/wp-content/themes/screenr-child/forum.js?ver=1.2"></script>
<script src="/wordpress/wp-content/themes/screenr-child/forum-mobile.js?ver=1.7"></script>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr-child/style.css?ver=2.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr-child/colors_common.css?ver=2.0" />
<style>@media screen{#breadcrumblistTop, #breadcrumblistTop .bbp-breadcrumb {background-color: rgb(3,33,43)!important;}}</style>
<?php  if(is_bbpress()){ ?>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr-child/forum-css.min.css" />
<?php }else{ ?>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr-child/colors_other.css" />
<?php }
} );
Huomaa, että bbPressin CSS tulee ehdollisena. Nimet on vanhasta teemasta osittain perua. Versionumerot on siksi, että cache ei hae vanhoja tiedostoja. Eräs nettituttu sanoi, että versiotiedot pitäisi poistaa, mutta ainakin teema niitä jättää. Luulisi, että jos versionumero ei ole muuttunut, selain hyödyntää cachea. Cacheen kaiketi jää roskana se vanha versio?

Sinun ansiostasi tämä teema alkaa jotenkin olla hallittuna eikä ole niin, että se hallitsee minua ainakaan kohtuuttomasti.
 
Siitä hallintapaneelista. Tässä siis toi Näytä/piilota on nyt vain itselläni - pitäisikö laittaa muille sama? Oletuksena se on minulla tietenkin piilossa, sillä en halua sitä aina nähdä.

Ihan oikeasti tuo Pikavalinnat on kiva. Tosin oppivatkohan muut sitä arvostamaan.
 

Liitteet

  • nimetön.png
    nimetön.png
    14,1 KB · Luettu: 29
Viimeksi muokattu:
Jossain on varmaankin
Koodi:
overflow: hidden

Toimii nimittäin skrollaus, jos body:n laittaa
Koodi:
overflow: auto
Olin varmaan jonnekin tyhmästi laittanut overflow:hidden. Ongelmaksi tuli se, että joillakin leveyksillä footerin alle jäi marginaalia, jota yritin pois. Tein paikon ja pakotin overflow:auto. Pitäisi joskus käydä body.home lävitse uudelleen.

Meikäläisen suurin heikkous on se, että seurannaisvaikutukset eivät ole aina hallussa. Siitä sain aikoinani eniten huomautuksia.. Jos olisin ollut huolellisempi, minusta olisi saattanut tulla huippukoodari.. Olisi toki edellyttänyt enemmän töitä.
 
Huomaa, että bbPressin CSS tulee ehdollisena. Nimet on vanhasta teemasta osittain perua. Versionumerot on siksi, että cache ei hae vanhoja tiedostoja. Eräs nettituttu sanoi, että versiotiedot pitäisi poistaa, mutta ainakin teema niitä jättää. Luulisi, että jos versionumero ei ole muuttunut, selain hyödyntää cachea. Cacheen kaiketi jää roskana se vanha versio?

Sinun ansiostasi tämä teema alkaa jotenkin olla hallittuna eikä ole niin, että se hallitsee minua ainakaan kohtuuttomasti.
Nuo kaksi ekaa add_actionia voi yhdistää samaan ja kannattaa nuo omatkin koodit lisätä noilla wp_enqueue_style() wp_enqueue_script() funktioilla, niin ei tarvitse sitten muokkailla kun saat sivustosi siirrettyä domainin juureen tuon wordpress hakemiston sijasta.
PHP:
add_action('wp_enqueue_scripts', function() {
    wp_dequeue_style('screenr-style');
    wp_dequeue_style( 'screenr-gallery-lightgallery');
    wp_dequeue_style( 'screenr-woocommerce' );
    wp_deregister_script( 'screenr-gallery-masonry');
    wp_deregister_script( 'screenr-gallery-justified');
    wp_deregister_script( 'screenr-gallery-carousel' );
    wp_deregister_script( 'screenr-gallery-masonry');
    wp_deregister_script( 'screenr-gallery-justified');
    wp_deregister_script( 'screenr-gallery-carousel');
    //isäteeman theme.js pois
    wp_deregister_script('screenr-theme');
    //oma tilalle
    wp_enqueue_script( 'screenr-theme', get_stylesheet_directory_uri() . '/assets/js/theme.js', array( 'jquery' ), '20120206', true );
}, 99);

add_action('wp_enqueue_scripts', function() {
    wp_enqueue_style('style-child', get_stylesheet_directory_uri() . '/style.css', [], wp_get_theme()->get('Version') );

    wp_enqueue_script( 'forum-child', get_stylesheet_directory_uri() . '/forum.js', [], wp_get_theme()->get('Version') );
    wp_enqueue_script( 'forum-mobile-child', get_stylesheet_directory_uri() . '/forum-mobile.js', [], wp_get_theme()->get('Version') );

    if(function_exists('is_bbpress') && is_bbpress()) {
        wp_enqueue_style('forum-style-child', get_stylesheet_directory_uri() . '/forum-css.min.css', [], wp_get_theme()->get('Version') );
    } else {
        wp_enqueue_style('colors-child', get_stylesheet_directory_uri() . '/colors_other.css', [], wp_get_theme()->get('Version') );
    }
}); // defaul prioriteetilla

// inline css headiin
add_action( 'wp_head', function () { ?>
<style>@media screen{#breadcrumblistTop, #breadcrumblistTop .bbp-breadcrumb {background-color: rgb(3,33,43)!important;}}</style>
<?php }
} );

Tuo assettien versionumerointi on ihan fiksua devaus- ja testausvaiheessa. Siinä kohtaa kun sivusto on tuotannossa ja jatkuvaa muutostarvetta ei ole, voi versioista luopua, mutta ei niistä nyt niin suurta haittaa ole, että kauheesti kannattaisi nähdä vaivaa. Ylläolevassa tuo versionumero siis kaivetaan lapsiteemvan style.css:n versionumerosta.
 
Siitä hallintapaneelista. Tässä siis toi Näytä/piilota on nyt vain itselläni - pitäisikö laittaa muille sama? Oletuksena se on minulla tietenkin piilossa, sillä en halua sitä aina nähdä.

Ihan oikeasti tuo Pikavalinnat on kiva. Tosin oppivatkohan muut sitä arvostamaan.
Lisääpä vielä tuohon pikavalinnat otsikkoon onclick listener, jolla palataan takaisin päävalikkoon. Ja aiheotsikkoon sama. Rasittaa liikutella hiirtä tuohon palaa päävalikkoon napin päälle jos haluaa vain kurkata mitä pikavalikon takaa löytyy ja haluaakin palata päävalikkoona.
 
listener? ei ole tuttu asia. Siis siihen koko valikon avaajan/sulkijan yhteyteydessä oleviin avaajiin?

Noissa kaikissa Pikavalinnat ja Aiheet linkeissä on vanhanaikaiset avaus/sulkukoodit, esim:
Koodi:
onclick="showTabA();return false" ja onclick="showTabB();return false"
Kirjoita koodi, mitä haluat lisättävän.

PS. Poistin vielä yhden lisäosan, jonka käyttöaste on lähes olematon. Nyt siivous on tehty paitsi että omissa CSS-tiedostoissa olisi vielä organisoitavaa.
Mitä teeman jne versionumeroihin tulee, enhän minä niille mitään mahda, vain omilleni.
 
Olin varmaan jonnekin tyhmästi laittanut overflow:hidden. Ongelmaksi tuli se, että joillakin leveyksillä footerin alle jäi marginaalia, jota yritin pois. Tein paikon ja pakotin overflow:auto. Pitäisi joskus käydä body.home lävitse uudelleen.
Tällä hetkellä etusivulta löytyy 132 kpl !important css säännöistä. Kannattaisi heti alkuunsa unohtaa koko !important olemassaolo. Nuo ovat omiaan saamaan aikaiseksi ylläolevan kaltaisia yllätyksiä.
 
listener? ei ole tuttu asia. Siis siihen koko valikon avaajan/sulkijan yhteyteydessä oleviin avaajiin?

Noissa kaikissa Pikavalinnat ja Aiheet linkeissä on vanhanaikaiset avaus/sulkukoodit, esim:
Koodi:
onclick="showTabA();return false" ja onclick="showTabB();return false"
Kirjoita koodi, mitä haluat lisättävän.

PS. Poistin vielä yhden lisäosan, jonka käyttöaste on lähes olematon. Nyt siivous on tehty paitsi että omissa CSS-tiedostoissa olisi vielä organisoitavaa.
Mitä teeman jne versionumeroihin tulee, enhän minä niille mitään mahda, vain omilleni.
Listener tai Handler mitä nuo nyt ovatkaan nimeltään. Mutta siis juuri tuollainen mitä olet käyttänytkin, jos et noita erikseen jqueryllä ole tehnyt. Pääasiana siis se, että myös tuota otsikkoa klikkaamalla pääsisi takaisin päävalikkoon.
 
Siis kun ollaan avattu Pikavalinnat ja halutaan takaisin päävalikkoon. Tässä on logiikka, mikä kyllä ei kokeilematta selviä. Voit nimittäin vaihtaa Pikavalinnat valikosta Aiheet valikkoon palaamatta päävalikkoon välillä. Siksi avaajassa ei ole sulkua vaan sulku on keskellä olevassa napissa, joka sulkee kumman tahansa avatun apuvalikon. Logiikkaa voi toki muuttaa, mutta sitten menetetään tuo vaihtomahdollisuus. Se erillinen vaihto on myös siksi, ettei vahingossa sulje apuvalikkoa.

jQueryllä piti alun perin tehdä muuten valikon avaajan/sulkijan vieressä olevat avaukset, mutta ei toiminut. Siinä oli kyllä logiikkavirhe.

Valikon avaukseen tarkoitettu jQuery oli ennen kuin itse avaajaa oli olemassa. Valikon vieressä olevia avaajia ei ole HTML-koodissa vaan ne luodaan jQueryllä. Sen kanssa pitää katsoa tarkkaan, mikä tulee ensin ja mikä jälkeen. Laitoin luonnin ihan ensimmäiseksi. JS:nkin kanssa voi tehdä logiikkavirheitä.

jQuer on joustava tapa ohjelmoida ja muistuttaa CSS:n luokkien käyttöä, mutta kyllä sitä silti tulee aina välillä käytetty onclick="" - kuten joskus style="".
 
Siis kun ollaan avattu Pikavalinnat ja halutaan takaisin päävalikkoon. Tässä on logiikka, mikä kyllä ei kokeilematta selviä. Voit nimittäin vaihtaa Pikavalinnat valikosta Aiheet valikkoon palaamatta päävalikkoon välillä. Siksi avaajassa ei ole sulkua vaan sulku on keskellä olevassa napissa, joka sulkee kumman tahansa avatun apuvalikon. Logiikkaa voi toki muuttaa, mutta sitten menetetään tuo vaihtomahdollisuus. Se erillinen vaihto on myös siksi, ettei vahingossa sulje apuvalikkoa.
Jos perusoletuksena on, että pikavalikon jälkeen halutaan avata aihevalikko, niin tuo logiikkasi tietysti toimii. Mutta jos avaan valikon, klikkaan pikavalikon auki ja totean, että eipäs täällä ollutkaan mitään mielenkiintoista ja haluan koko valikon sulki, pitää ensin siirtää hiirtä oikealle klikatakseen palaa päävalikkoon ja sitten vasemmalle ruksista sulkemaan valikko. Jos pikavalikon saisi kiinni suoraan otsikosta, jäisi tuo hiiren heiluttelu oikeaan pois.
 
Tuossa on tavallaan kolme keskenään vaihdettavaa osaa. Edellisellä kerralla ne kaikki kolme oli esillä välilehdissä. Nyt vain kaksi, nytkin yhdellä klikillä voit vaihtaa valikosta toiseen. Tätä nyt ei voi vääntää rautalangasta. Tosin se ei nyt vielä ihan toimi, sillä avaus/sulkupainikkeen kohdalla alussa olevat linkit rullautuvat.

Mitäs jos kiinnittäisin ne ja laittaisin keskelle entiseen tapaan PÄÄVALIKKO ja laittaisin sen oletuksena entiseen tapaan korostettuna? Pudottaisin samalla pois yhden palan rakenteesta eli sen, jossa lukee PALAA.... Valikon avaava/sulkeva ruksi, sekä PIKAVALINNAT, PÄÄVALIKKO ja AIHEET pitäisi mahtua samalle riville siedettävällä fontilla kännykässäkin. Kännykkäleveyksissä tilasta alkaa olla pulaa. Tuossa myös logiikka olisi selkeä heti eikä sitä tarvitsisi kokeilemalla hakea. Siinä olisi käyttäjälle pieni huijaus. PÄÄVALIKKO kohdalla ei avattaisi päävalikkoa, niinkuin käyttäjä voisi olettaa, vaan vain poistettaisiin mahdollisesti päällä oleva apuvalikko näkyvistä. Selaaja luulisi systeemin toimivan hieman eri lailla kuin se todellisuudessa toimii.

No hiirtä tulisi kyllä liikuttaa tuossakin tapauksessa sivusuunnassa, joten siihen asiaan ei olisi parannusta. Mutta vaihtaminen olisi kaiketi selkeämpää.. En siitä hiiren liikuttelusta oikeaan ole luopumassa. Mutta ehkä voin tehdä siitä mielekkäämpää.

Koko valikko sulkeutuu klikkaamalla sisältöalueita - samalla menee kiinni kaikki avatut apuikkunat. Myös ruksin painaminen sulkee kaikki apuikkunat. Vain jos on pikavalinnoissa ja avaa apuikkunan, se pitää erikseen sulkea, jos haluaa vielä muuta katsoa.
 
Viimeksi muokattu:
Tein edellisessä kommentissa lupaamani muutokset. Nyt ainakin käyttäytyy valikkopainikkeet siististi. Siinä on siis illuusio siitä, että on valikot ovat kolmessa erillisessä välilehdessä. Siistimmäksi lopputulosta en saa, mutta väreistä saa esittää eriäviä mielipiteitä. Täytyy tutkia vielä toimivuus kännykkäleveyksillä.
 

Liitteet

  • 2021-05-17 10.27.34 www.sanaristikkofoorumi.net b5a43bc0afdd.png
    2021-05-17 10.27.34 www.sanaristikkofoorumi.net b5a43bc0afdd.png
    11,1 KB · Luettu: 41
Tuo harmaa väri ainakin on tosi huono. Liian vähän kontrastia.
Valkoinen tai jokin muu mikä erottuu selkeästi.
 
Vaihdoin normal-tab värin mustaksi. Harmaa oli valikon normiväri. Valkoista taustaa vasten toimii, mutta tosiaan tuli liian huono kontrasti.
Lisäsin aktiiviseen tabiin 1px varjostuksen, jotta erottuu paremmin.

Jos korkeutta vähintää 700px Google-haku on nyt kiinnitetty. Matalassa näytössä ei voi, koska nappaa liikaa tilaa.

Jos nyt joskus saisi aikaiseksi sen hälytyksen, välilehtien yläpuolella on tyhjää tilaa, johon voi jQueryn avulla luoda tämän sivuston hälytyssysteemin tulostamisen näytölle. Toinen vaihtoehto sille olisi oikea reuna, jossa se häviäisi sen jälkeen kun sen kohdat on käyty lävitse.
 

Liitteet

  • 2021-05-17 11.09.28 www.sanaristikkofoorumi.net f4f891651e51.png
    2021-05-17 11.09.28 www.sanaristikkofoorumi.net f4f891651e51.png
    14,4 KB · Luettu: 31
Viimeksi muokattu:
Sitten on kyllä mulla myös tietoturvan kannalta aika ikävä ongelma. Asensin Googlen Captcha-lisäosan, mutta se vuotaa. Kirjautuminen päästää joskus läpi XXX@errorid.com rekisteröintejä

Jos Googlen lisäosa ei kunnolla integroidu WordPressin, se pitää koodata itse, mistä tietenkin seuraa päivitysongelmia.
Googlen lisäosa pitää ottaa pois käytöstä ja pitää tehdä ohjeiden mukaan jokaiseen neljään lomakkeeseen:
  1. kirjautumislomake - voi vaatia ydinkoodin sorkkimista, mistä seuraa päivytysongelmia
  2. uuden kommentin lomake muiille sivuille - en tiedä vielä, onko helppoa mahdollisuutta lisätä koodia; päivitysongelmat ovat mahdollisia
  3. uuden aiheen lomake - tästä on mallinne, jonne helppo lisätä koodia
  4. uuden kommentin lomake foorumiin - tästä on mallinne, johon on helppo lisätä koodia

bbPressin mallinteisiin sen saattaa varsin hyvin integroida do_action( 'bbp_theme_before_topic_started_in' ); tms. koukuilla.
Mutta mihin kohtaa FORM-elementtiin nähden Googlen systeemi pitää sijoittaa.

Ei tuo taida toimia. Lomake liitetään tähän tapaan eli pitää peukaloidan lomakkeen luovaa koodia.
Koodi:
        <?php bbp_get_template_part( 'form', 'reply' ); ?>
 
Viimeksi muokattu:
Nuo kaksi ekaa add_actionia voi yhdistää samaan ja kannattaa nuo omatkin koodit lisätä noilla wp_enqueue_style() wp_enqueue_script() funktioilla
Mutta mikä vika on add_action( 'wp_head', function () { ?> käytössä?
Jos heittäisi pois kaikki JS- ja CSS-linkitykset, mitä WP ja teema on luonut, voisi itse linkittää kaikki suhteessa palvelimen juureen eikä käytettäisi turhaan nimipalvelinta https://... alkuisiin osoitteisiin.

yritin tätä

Koodi:
wp_dequeue_style( 'font-awesome-css');
wp_dequeue_style( 'bootstrap-css');
korvata
Koodi:
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr/assets/css/font-awesome-css?ver=4.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr/assets/css/bootstrap-css?ver=4.0" />

mutta teema ei suostunut yhteistyöhön. Teeman tekijät ovat selvästikin yrittäneet tehdä muutosten teon vaikeaksi.
Ne muutokset, jotka viimeksi tehtiin, toimivat sen jälkeen kun päivitin teeman (muutin versionumeron, että sain päivitettyä).

!important - no kun on paikkoja paikkojen perään eikä ikinä tunnu olevan aikaa laittaa kaikkea ihan järjestykseen.

Testasin valikoiden avaajia vaimon känykällä - toimii, mutta viewport-arvo ei saa kyllä olla pienempi kuin mitä on Samsung Galaxy J5:ssä eli 360px. Pienensin fonttikokoa pienemmille viewport-arvoille sekä vähensin padding-arvoja.

Siitä testaamisesta.
PHP:
if(current_user_can('activate_plugins')) {
    // do stuff
}
Tämä nyt ei ihan suoraan kerro, onko kyseessä admin tason käyttäjä, mutta wp:n perusasennuksessa vain admin saa aktivoida plugineja. Lisää testattavia oikeuksia täältä:
Itse asiassa bbPress käyttää vastaavaa
Koodi:
if ( current_user_can( 'moderate', bbp_get_reply_id() ) )
 
Viimeksi muokattu:
!important - no kun on paikkoja paikkojen perään eikä ikinä tunnu olevan aikaa laittaa kaikkea ihan järjestykseen.

Testasin valikoiden avaajia vaimon känykällä - toimii, mutta viewport-arvo ei saa kyllä olla pienempi kuin mitä on Samsung Galaxy J5:ssä eli 360px. Pienensin fonttikokoa pienemmille viewport-arvoille sekä vähensin padding-arvoja.

Etsi itsellesi aikaa laittaa tyylit järjestykseen, helpottaa kaikkea mitä teet jatkossa. Tuo on perinteinen tuoteomistajan virhe, tehdään uutta ennen kuin vanha on tehty kunnolla, nytten olet recaptchaa (heh, ootas kun löydät että recaptcha v2 ei toimi kunnolla pienillä resoilla :D) tms lähtenyt virittämään ennen kuin perus asiat on kunnossa. Ethän taloa rakentaessa tee perustuksia vähän sinneppäin koska "ne voi korjata myöhemmin"? Olen työkseni tehnyt WP sivuja ja voin kokemuksesta sanoa että jos et siivoa importantteja pois niin tulet hakkaamaan päätä seinään (olet varmaan jo huomannut että hakkaat päätä seinään jo nyt tyylien kanssa?) aina kun yrität muuttaa tyylejä.

Eikä noita resoluutioita varten tarvitse eri laitteita etsiä vaan käytä (esim) chromesta löytyvää device toolbaria, löytyy DevToolseista vasemmasta reunasta:
Screenshot 2021-05-17 at 16.43.15.png

Sitten vain valitset ylhäältä "responsive" niin saat kokeiltua kaikki resoluutiot 2560px asti riippumatta näytön oikeasta resoluutiosta.
 
Tiedän, että CSS on vähän sekaisin, kun on tullut on tullut väliaikaismuutoksia, joihin laittaa !important eikä ole tullut laitettua muutosta alkuperäiseen kohtaan, jotta !important sais pois käytöstä. Ongelmana on, että tulee liian syvästi joskus määriteltyjä tyylejä, jolloin elementtiketju tuppaa venymään liian pitkäksi. Ei paikattua CSS:ää hirveästi ole, mutta kyllähän parempi järjestys auttaisi.

Aina välillä se on suht. järjestyksessä, mutta sitten tulee koikeiltua taas jotain uuttaa ja pakkohan sitä jotenkin on ajaa aiempaa yli kun ei malta ruveta etsimään isosta CSS-tiedosta juuri sitä kohtaa, mitä pitäisi muuttaa. Olisi toki järkevämpää hakea se tyyli isosta tiedosta ja muuttaa suoraan siihen. Työskentely on vähän liian impulsiivista.

Kun tulee tehtyä muutoksia paljon, halusin kokonaan eroon teeman alkuperäisestä CSS:stä ja jätin sitä niin vähän kuin uskalsin, jotta se ei sotkisi.

Siivoamista on se, että otin pois käytöstä teeman ison CSS-tiedoston ja monta JS-tiedostoa.

Kyllä minä ymmärrän, että isoa resoa voi tietyllä tavalla testata, mutta siitä ei saa kunnollista kuvaa, mitä oikeassa isossa näytössä todellisuudessa tuntuu. En siksi edes yritä katsoa isoja kokoja vaan heitän arvauksen.

Pientä laitetta voi isolla näytöllä paremmin testata, kun minulla kännykkäleveys on melkein sama kuin minkä kokoinen kännykkä oikeasti on.

Tietokonella ja mobiililaitteella muuten lähes identtinen ulkoasu. Googlen hakua piti hieman säätää erilaiseksi mobiililaitteille ja tietokoneelle.

Googlen haku on siksi, että muuten ei ole koko sivustolle hakua. Kaksi eri hakua tuntuisi tyhmältä ja näyttäisi todella idioottimaiselta.

Mutta Chapta on ihan eri juttu. Sekin olisi syytä saada toimimaan kunnolla. En ymmärrä miksi Captcha ei kunnolla blokkaa robotteja pois. Onko Googlen Captcha huono vai onko koodissani jotain, joka heikentää sen toimintatehoa. Mitään lomakkeiden käsittelyyn liittyvää ei pitäisi olla.
 
Viimeksi muokattu:
Mutta mikä vika on add_action( 'wp_head', function () { ?> käytössä?
No ei tuossa nyt varsinaisesti mitään vikaa ole, mutta kun kerta WP tarjoaa omat toimintonsa tyylien ja scriptien sisällyttämiselle, niin miksipä niitä ei käyttäisi. Lisäksi nuo tarjoavat automaatiota riippuvuuksien osalta. Ja vielä halutessasi saat yhtä funktion argumenttia vaihtamalla nuo joko headeriin tai footeriin.
yritin tätä

Koodi:
wp_dequeue_style( 'font-awesome-css');
wp_dequeue_style( 'bootstrap-css');
korvata
Koodi:
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr/assets/css/font-awesome-css?ver=4.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr/assets/css/bootstrap-css?ver=4.0" />

mutta teema ei suostunut yhteistyöhön. Teeman tekijät ovat selvästikin yrittäneet tehdä muutosten teon vaikeaksi.
Ota dequeue- kutsuista -css nimistä pois.
kts.

!important - no kun on paikkoja paikkojen perään eikä ikinä tunnu olevan aikaa laittaa kaikkea ihan järjestykseen.
Kyllä näihin tosiaan kannattaisi puuttua heti alkuunsa. Minkä taaksesi jätät, sen edestäs löydät :)
 
Kiitti virheen korjauksesta. Toimii. Muutama väärin kirjoittaminen vähän sotki.

WP tarjoaa omat toimintonsa tyylien ja scriptien sisällyttämiselle, niin miksipä niitä ei käyttäisi.
add_action( 'wp_head',... tuntuu vain niin simppeliltä koodata. Mutta kuten tuli esille theme.js kohdalla joskus ainakin on syytä käyttää esittämiäsi tapoja.
Sitäpaitsi WordPress käyttää nimipalvelua ja aloittaa tiedostonimet https://. Jos ne saa korvattua jollakin tavoin relatiivisilla poluilla, hyvä on.
Tein suuren luokan suursiivousta ennen omiin pikku sotkuihini puuttumista. Heitin pois käytöstä Monserrat Google-fontin, joka on turhaa hienostelua sivustolle. Muutin kaikki https://...polut, jotka pystyin relatiivisiksi poluiksi. Kiitos sinulle, että tähän suursiivouksen pystyin tekemään.

Tää näyttää ehkä sinusta vähän brutaalilta, mutta toimii ja on erittäin selkeä ylläpitää ja lukea.
Koodi:
add_action('wp_enqueue_scripts', function() {
wp_dequeue_style( 'screenr-style');
wp_dequeue_style( 'font-awesome');
wp_dequeue_style( 'bootstrap');        
wp_dequeue_style( 'dashicons');    
wp_dequeue_style( 'admin-bar');    
wp_dequeue_style( 'wp-block-library');
wp_dequeue_style( 'bbp-default');    
wp_dequeue_style( 'moderation-tools-bbpress');    
wp_dequeue_style( 'admin-bar-style');    
wp_dequeue_style( 'gdatt-attachments');    
wp_dequeue_style( 'wgs2');
wp_dequeue_style( 'screenr-gallery-lightgallery');
wp_dequeue_style( 'screenr-woocommerce' );
wp_dequeue_style( 'screenr-fonts' );
wp_dequeue_style( 'gdbto-front' );
},99);

add_action( 'wp_head', function () { ?>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr/assets/css/bootstrap.min.css?ver=4.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr/assets/css/font-awesome.min.css?ver=4.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-includes/css/dashicons.min.css?ver=5.7.2'" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-includes/css/admin-bar.min.css?ver=5.7.2" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-includes/css/dist/block-library/style.min.css?ver=5.7.2" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr-child/css/bbpress.min.css?ver=2.6.6" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/moderation-tools-for-bbpress/css/front.css?ver=1.2.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/wp-analytify/assets/old/css/admin_bar_styles.css?ver=4.0.3" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/gd-bbpress-attachments/css/front.min.css?ver=4.2_b2420_free" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/wp-google-search/wgs2.css?ver=5.7.2" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/gd-bbpress-tools/css/front.min.css?ver=3.1_b2310_free" /><link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr-child/style.css?ver=2.0" />
<?php
},2 );

Muutin 12 kpl CSS-tiedostoja relatiivisille poluille ja poistin kolme kokonaan käytöstä. Teeman style-tiedostostakin on lähes puolet lähtenyt. On se aika siivous.

Jostakin syystä seuraavaa:
Koodi:
get_stylesheet_directory_uri() . '/
Ei voi korvata relatiivisella polulla:
Koodi:
'/wordpress/wp-content/themes/screenr-child/assets/js/theme.js'

Jälkimmäisessä tapauksessa tuli väärä hakemisto. Anteeksi vaan hyvä WP-guru (olet kyllä todellinen osaaja), hylkään sinun ehdotuksesti määrittää oma JS ja CSS WP:n tyylihallintafunktioilla. Laitoin tämänkin wp_head()..., koska muuten en saa sille relatiivista polkua. Saman tein WP:n ydin JS:lle. WP:n ja teeman JS-tiedostoja on siten kolme muutettu relatiivisille poluille.

Sain siis yhteensä 15 kpl https://... alkuista CSS ja JS-tiedostoa käyttämään relatiivisia polkuja. Oli hieno tietää, miten WordPressin oma tyylien ja JS-tiedostojen määritys pystytään ohittamaan. Ohitan jatkossa sen aina kun mahdollista. Jos katsot lähdekoodiani, siinä ohitetut tiedostot on siististi allekkain. Ensin ohitetut WP:n & teeman CSS-tiedostot ja sitten JS-tiedostot. Lopuksi ihan omat JS- ja CSS-tiedostot. Lähdekoodi on järjestyksessä - omat CSS-tiedostoni eivät.

JS-tiedostojen poisto käytöstä poisti myös swiper-efektin. Mutta jos JS:n poistolla saa nopeutta, menköön. Mutta jos swiperin JS on poissa pelistä, sitten olisi järkevää poistaa se style.css-tiedostostakin. Jäiköhän jonnekin silti jotain swiperiin liittyvää kutsua. Mitähän pitäisi ottaa käyttöön, jotta swiper-efekti pelaisi? Oli kyllä ihan kiva, vaikka aika tarpeeton. Nyt en oikein tiedä, mitä sen kanssa kannattaisi tehdä.

Tällä palvelimella ei ehkä kannata hienostella vaan ehkä parempi jättää swiper-efekti pois. bootstrap näemmä täytyy pitää, jos ei halua määrittää CSS:ää uusiksi sisällön asettumisen suhteen. Tuli valittua vähän liikaa JS:ää käyttävä teema jos ajatellaan käyttötarkoitusta. Mutta voihan systeemiä sentään peukaloida.

Oman CSS siistiminen vie sitten enemmän aikaa.
 
Viimeksi muokattu:
Poistin liikaa käytöstä, mutta en halua palauttaa turhia. Kokeilin palauttaa käyttöön muille kuin foorumiosiolle

Mainittuja lisäyksiä, mutta relatiivisilla poluilla add_action( 'wp_head' käyttäen. Siinä on muutamat JS-tiedostot kahteen otteeseen. Onko todella tarpeen sama tiedosto hakea kahteen kertaan?

Foorumilla on nyt mimini toimiva kokonaisuus, mutta muut sivut eivät pelaa kuin pitäisi. JS:n osalta add_action(... ei ihan sellaisenaan toimi vaan vaatisi vähän korjailua. Chromen konsoli valitti foorumisivuilla näistä kohdin:

Koodi:
// varoitukset
jquery.min.js?ver=3.5.1:2 jQuery.Deferred exception: Screenr is not defined ReferenceError: Screenr is not defined
    at HTMLDocument.<anonymous> (https://www.sanaristikkofoorumi.net/wordpress/wp-content/themes/screenr-child/assets/js/theme.js:294:23)
    at e (https://www.sanaristikkofoorumi.net/wordpress/wp-includes/js/jquery/jquery.min.js?ver=3.5.1:2:30005)
    at t (https://www.sanaristikkofoorumi.net/wordpress/wp-includes/js/jquery/jquery.min.js?ver=3.5.1:2:30307) undefined
S.Deferred.exceptionHook @ jquery.min.js?ver=3.5.1:2
jquery.min.js?ver=3.5.1:2 jQuery.Deferred exception: $(...).counterUp is not a function TypeError: $(...).counterUp is not a function
    at HTMLDocument.<anonymous> (https://www.sanaristikkofoorumi.net/wordpress/wp-content/themes/screenr-child/assets/js/theme.js:875:19)
    at e (https://www.sanaristikkofoorumi.net/wordpress/wp-includes/js/jquery/jquery.min.js?ver=3.5.1:2:30005)
    at t (https://www.sanaristikkofoorumi.net/wordpress/wp-includes/js/jquery/jquery.min.js?ver=3.5.1:2:30307) undefined
// virheilmoitukset
    at HTMLDocument.<anonymous> (theme.js:294)
    at e (jquery.min.js?ver=3.5.1:2)
    at t (jquery.min.js?ver=3.5.1:2)
jquery.min.js?ver=3.5.1:2 Uncaught TypeError: $(...).counterUp is not a function
    at HTMLDocument.<anonymous> (theme.js:875)
    at e (jquery.min.js?ver=3.5.1:2)
    at t (jquery.min.js?ver=3.5.1:2)

Nuo voisi yrittää korjata. Alla kohdat theme.js-tiedostossa:

Koodi:
    // Add active class to menu when scroll to active section.
    if ( string_to_bool( Screenr.is_home_front_page ) ) { // rivi 294
        // Navigation click to section.
   
      $('.counter').counterUp({ // 875
Muilta sivuilta tuli bootstap.bundle-liittyen virhe, mutta puuttui bootstrap.min.js. Kun lisäsin korjaantui. bootstrap kyllä huomautti, että
WP:n jquery on liian vanha ja pitäisi hankkia tilalle 9.x
Lomakesivu valittaa vielä:
Koodi:
Uncaught (in promise) Error: Invalid site key or not loaded in api.js: 6Lei_s8aAAAAAC-POA7hnLOMQOMv8BvWUh0zLLCQ
    at Array.<anonymous> (recaptcha__fi.js:356)
    at recaptcha__fi.js:344
    at wpformsRecaptchaLoad ((index):703)

DevTools failed to load SourceMap: Could not load content for https://www.sanaristikkofoorumi.net/wordpress/wp-content/themes/screenr/assets/js/bootstrap.bundle.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

Idea minulla on, että foorumiosiossa kaikki mahdollinen veks, sillä siinä nopeus on valttia. Pois saa olla swiper, mutta swiper saisi tulla takaisin muille sivuille. Ei näemmä oikein onnistu JS:n kohdalla.
 
Viimeksi muokattu:
Tämä onkin hankala tapaus.

Koodi:
wp_deregister_script('screenr-theme'); //isäteeman theme.js pois
wp_enqueue_script( 'screenr-theme', get_stylesheet_directory_uri() . '/assets/js/theme.js', array( 'jquery' ), '20120206', true );

Ei voi käyttää - swiper lakkaa toimimasta (haluan sitä normaalisivuilla käyttää). Ei käy myöskään add_action( 'wp_head' On siis pakko yliajaa alkuperäinen tiedosto, jos haluaa, että swiper toimii.

Osa JS:ää pitää olla sivun lopussa. Ehkä wp_footer voisi kokeilla joillekin JS-tiedostoille.. Jotenkin WP nyt ottaa nokkiinsa, jos sen JS:n hallintaa yritetään ohittaa. Ainoa järkevä ohitus taitaa olla se, että jos jokin lisäosa on vain bbPressille, se pois muilta sivuilta ja päinvastoin. Mielellään noista JS-tiedostoista vain tiputtaisi pois https://...

En poistanut siis mitään JS:ää normaalisisivuilta yhtä bbPress-lisäosaa lukuun ottamatta, mutta silti jäi valitus:
Koodi:
jquery-migrate.min.js?ver=3.3.2:2 JQMIGRATE: Migrate is installed, version 3.3.2
DevTools failed to load SourceMap: Could not load content for https://www.sanaristikkofoorumi.net/wordpress/wp-content/themes/screenr/assets/js/bootstrap.bundle.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

Tein nyt CSS:n käytön samalla logiikalla jolla loin Pikavalinnat - vain kulloinkin tarpeellinen CSS käytössä:
Koodi:
// palautettu CSS
add_action( 'wp_head', function () { ?>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr/assets/css/bootstrap.min.css?ver=4.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr/assets/css/font-awesome.min.css?ver=4.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-includes/css/dashicons.min.css?ver=5.7.2'" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/wp-google-search/wgs2.css?ver=5.7.2" />
<?php if(!is_bbpress()){ ?>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/wpforms-lite/assets/css/wpforms-full.min.css?ver=1.6.7">
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr/assets/css/lightgallery.css" />
<?php }else { ?>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/gd-bbpress-attachments/css/front.min.css?ver=4.2_b2420_free" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/themes/screenr-child/css/bbpress.min.css?ver=2.6.6" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/gd-bbpress-tools/css/front.min.css?ver=3.1_b2310_free" />
<?php }
},2 );

add_action( 'wp_head', function () { if(is_user_logged_in() && (is_bbpress())){ ?>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-includes/css/admin-bar.min.css?ver=5.7.2" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-includes/css/dist/block-library/style.min.css?ver=5.7.2" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/moderation-tools-for-bbpress/css/front.css?ver=1.2.0" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/wp-analytify/assets/old/css/admin_bar_styles.css?ver=4.0.3" />
<?php }elseif(is_user_logged_in()){ ?>
<link rel="stylesheet" type="text/css" href="/wordpress/wp-includes/css/admin-bar.min.css?ver=5.7.2" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-includes/css/dist/block-library/style.min.css?ver=5.7.2" />
<link rel="stylesheet" type="text/css" href="/wordpress/wp-content/plugins/wp-analytify/assets/old/css/admin_bar_styles.css?ver=4.0.3" />
<?php }
},2 );

Tuon nyt olisi voinut spesifioida vieläkin tarkemmin, mutta tuo riittänee.

Kirjautumattomille kävijöille, joilla ei ole taustakäytön CSS:ää riesana, tavalliset sivut suorastaan lentävät silmille. Joskus joku foorumi vähän hidastelee, mutta usein foorumisivut vaihtuvat nopeasti. Harmi, etten saanut JS:ää toimimaan relatiivisilla osoitteilla. Ehkä pitää joskus kokeilla wp_footer kanssa, mutta voi olla että sekään ei auta.
 
Viimeksi muokattu:
Sitäpaitsi WordPress käyttää nimipalvelua ja aloittaa tiedostonimet https://. Jos ne saa korvattua jollakin tavoin relatiivisilla poluilla, hyvä on.
Tein suuren luokan suursiivousta ennen omiin pikku sotkuihini puuttumista. Heitin pois käytöstä Monserrat Google-fontin, joka on turhaa hienostelua sivustolle. Muutin kaikki https://...polut, jotka pystyin relatiivisiksi poluiksi.
En tiedä mistä olet sellaisen käsityksen saanut, että absoluuttiset urlit olisi jotenkin huono asia. Ei se selain tee jokaisen samaan hostiin osoittavan urlin kohdalla uutta nimipalvelinkyselyä. Kun sivulle ollaan siirtymässä, tekee selain maksimissaan yhden nimipalvelinkyselyn ja kaikki loput saman hostin kyselyt tulee selaimen dns välimuistista. Ja kaiken lisäksi selain pitää ensimmäisen resurssin latauksen jälkeen yhteyden palvelimelle auki (riippuen tietysti palvelimenkin asetuksista) ja lataa samaan palvelimeen osoittavat kyselyt käyttäen samaa yhteyttä. (yksinkertaistin ja oioin vähän mutkia, mutta pääpiirteittäin noin)

Pahimmillaan noista relatiivisista poluista on vain haittaa. Ainakin itsellesi, jos joskus päätät siirtää sivuston pois tuolta wordpress alihakemistosta, niin joudut käymään kaikki nämä omat lisäyksesi läpi. Eli toistan suositukseni, käytä niitä wp_enqueue_script() ja wp_enqueue_style() funktioita.
 
Jos siirrän juureen, kaikki muutokset käy yhdellä etsi ja korvaa -komennolla.
Joku koodaaja piti https:// aina vähän epävarmana, jos nettiliikennettä on paljon ja nimipalvelinta joudutaan kysymään. Palvelimen cache taitaa kyllä auttaa uuttakin käyttäjää, vaikka selaimen cache olisi tyhjä.

Eräs koodaaja suositti, että niin paljon kuin mahdollista käyttäisin relatiivisia polkuja. CSS:n kanssa se onnistuu muidenkin luoman CSS osalta, jos vain CSS-tiedostossa on id="css-nimi-css", mutta ei onnistu JS:n kanssa jos yrittää poistaa tietyn JS:n käytöstä ja määrittää sille relatiivisen polun wp_head()..., . Konsoli huomauttaa aina virheestä jos niin tekee. WP luulee, että niitä ei ole käytössä vaikka onkin.

Tein vain sen, että poistin tietyn JS:n käytöstä, jos sitä ei tarvita jossakin tilanteessa.

Ja kuten kerroin, se theme.js heittää virheen, jos sen määrittää muualle kuin teeman päähakemistoon. Sitä ei voi osoittaa muualle, wp_dequeue_script() & wp_enqueue_script(), jos ei jotenkin osaa korjata konsolin osoittamaa virhettä. Se valittaa, että Screenr ei ole määritetty. Sekään ei JS:n suhteen aina toimi.

Sain kaiken ulkoa tulevan CSS:n järjestykseen, mutta oman CSS:n järjestäminen täysin, osoittautui ylivoimaiseksi. Olen parina päivänä yrittänyt kunnon organisointia, mutta siitä vaan ei tule mitään. Menee aina jostakin kohti rikki, jos yritän muuttaa CSS-koodia. Sitten on otettava käyttöön toimivin varakopio. Onneksi pidän varakopioita riittävästi.

CSS meni hieman turhan kompleksiksi. Osa koodista on tarkoituksella PHP + CSS -yhdistelmällä CodeSnippetillä. Mutta osa CSS:stä oli tarkoitus siirtää tiedostoihin, mutta se nyt vaan ei onnistunut. Se style-element on sekavan näköinen ja hieman onkin, mutta se toimii. Sekavuusaste ei ole paha. Naurattaa varmaan, että näin kävi.

Joo, olen täysin tietoinen, että jos nyt vielä haluan jotain ulkoasumuutosta, tiedossa voi olla paha kaaos. Tähän ulkoasuun ei paranisi enää koskea, jos ei halua sitä taas rikki. Tämä nyt tietenkin oli ihan kaikille odotettavissa oleva tilanne. ;D
 
Viimeksi muokattu:
Mukava huomata että valikon osalta on tapahtunut edistystä. Noihin nappien väreihin voisin melkeimpä suositella palettien googlailua jos ei ketään visuaalisesti lahjakasta kaveria löydy lähipiiristä. Tuo valkoinen fontti mustalla reunalla pistää ikävästi silmään (valikossa). Ihan rehellisesti valkoinen voisi toimia.

Vielä kun mobiilista saat tuon taustan scrollaantumisen estettyä niin on huomattavasti parempi.
 
Laitoin mustan reunan ajatellen, että erottuu - mutta näemmä erottuu vähän liiankin terävästi. Toi punertava on teeman linkin korostusväri, joka on aktiivisessa välilehdessä samana kuin linkin korostuksessa ja ei-aktiivisessa vaaleampana. Jos vaihtaa sitä, pitäisi ehkä vaihtaa linkin korostusväriäkin? Voihan ne toki itsenäisestikin määrittää.

En tiedä, miten taustan skrollaamista voisi hallita. Auttaisiko valikolle ja apuvalikoille fokuksen asettaminen? :focus liittyy ymmärtääkseni vain linkkeihin eli taidetaan mennä JS:n puolelle?
 

Statistiikka

Viestiketjuista
258 706
Viestejä
4 496 439
Jäsenet
74 273
Uusin jäsen
Aloittelija6271

Hinta.fi

Back
Ylös Bottom