PHP.EE FOORUM   
Nimi:   Pass:   Mäleta mind! 
   Teemad | php.ee esilehele | registreeri | Märgi kõik teemad loetuks | #php.ee Skype vestlus | RSS
UUS TEEMA  OTSI  Lehekülgi: 1
Woocommerce kategooriate koodamine ühele lehele
Postitaja: Wordpressikas 2017-08-28 17:46:20
Tere,

Soovin koondada mitme tootekategooria tooted ühele lehele. Pikalt otsisin ja leidsin, et kui kategooriad urli lisada ja eraldada need komadega, siis asi peaks toimima. Nii ja naa toimibki.
https://aadress.xx/tootekategooria/laadijad,akupangad/

Tooted kuvatakse vaid esimesest kategooriast, ehk laadijad.

Naljakas on see, et kategooria päises näidatakse todoete arvuks mõlema kategooria summana.

Ilmselt lähenen asjale valesti.

Proovisin siis genereerida lehe templiidi ja koondada sinna erinevate kategooriate tooted. Lebo, see töötas. Kuid sellisel juhul ei tööta enam woocommerce widgetid sidebaril. Tuleb välja, et woocommerci widgetid toimivad vaid archived.php lehel.

No egas midagi hakkasin siis ise sidebari kirjutama. Ja seal siis jooksis juba aju kokku ja edasi ei tahaks seda teed minna, sest ilmselgelt on ka see vale.


Ehk siis Teie soovitus oleks ?

RE: Woocommerce kategooriate koodamine ühele lehele
Postitaja: .:|:. 2017-08-29 10:09:55
TSITEERITUD:

Ehk siis Teie soovitus oleks ?

Telli töö asjatundjalt
RE: Woocommerce kategooriate koodamine ühele lehele
Postitaja: Wordpressikas 2017-08-29 20:16:02
TSITEERITUD:
Telli töö asjatundjalt


Tark nõuanne. Aga ei

Ühesõnaga ma sain siis nüüd nii kaugele et lisasin function.php faili ühe koodijupi. Nüüd saan kõikide soovitud kategooriate tooted ühele lehele. Kuid lehe templiit pole enam mitte poe oma vaid tavalise blogi oma.


PHP kood:
 function multiple_categories($query) {
    
    
$cat_names $query->get('product_cat');
        if (
$cat_names == 'laadimine') {
            
$query->set'post_type', array( 'product' ) );
            
$query->set('product_cat'$cat_names ',akupangad,laadijad');
            
        }
    
}
add_action('pre_get_posts''multiple_categories');
RE: Woocommerce kategooriate koodamine ühele lehele
Postitaja: Wordpressikas 2017-08-29 20:17:17
Ehk saaks siin kohal nüüd abi. Kuidas ma saan määrata, et ta võtaks templiidiks just /woocommerce/archive-product.php faili
RE: Woocommerce kategooriate koodamine ühele lehele
Postitaja: progreja_keda_HR_osakonnad_r2mpsuks_peavad 2017-08-30 02:22:12

Teile tõenäoliselt minu praegune vastus ei meeldi, aga
eks ma siis olen ikkagi see halbade uudiste üle andja:
MIDA IGANES TE KA VALMIS TEETE, ÜKSKÕIK KUI KAVALALT
JA TOREDALT, LAKKAB TOIMIMAST HETKEL, MIL SELLE WOOCOMMERCE
KOOD MÕNE WOOCOMMERCE UUE VERSIOONI KASUTUSELEVÕTUL MUUTUB.

Teisiti sõnastatult, palun tehke OMA ENDA KOOD viisil, et
Wordpressi ja selle pluginate muutuse tingimustes
TEIE KOODI EI TULE MUUTA. Vastupidisel juhul peate
"upstream" muutuste saabudes hakkama sama tööd
OTSAST PEALE, NULLIST SAADIK, tegema.

Minu postituse ülejäänud arutelu on teemal, et
kuidas Te saate luua Wordpressi ja
ta pluginate muudatuste suhtes võimalikult
töökindla koodi.

----------------selgituse--algus---------------------------

Esimene reegel tarkvara-arhitektuuri koostamisel on, et
kõik hiljem, tulevikus, väljavahetatav tuleb mähkida
loodava rakenduse spetsiifilisse kihti ja loodava rakenduse,
Teie korral toodete ühis-nimekirja, kogu ülejäänud kood
tohib kasutada neid muutuvaid asju ainult läbi tolle,
Teie poolt loodud, kihi. Antud juhtumil on Teil muutuvaks asjaks
Wordpress ja selle pluginad, mis muutuvad Wordpressi ja/või
tema pluginate versiooniuuenduste käigus.

Konkreetsemalt rääkides, palun pange kogu selline kood,
mis kutsub välja midagi WordPressi
või tema pluginate koodist, oma enda PHP-klassi.
Ideaaljuhul ei tohiks Te oma PHP-koodist WordPressi
ning tema pluginate poolt kirjutatava/loetava andmebaasi poole
otse pöörduda, vaid peaksite proovima hakkama saada
WordPressi/Woocommerce avaliku API-ga, sest tõenäoliselt
andmebaasi formaat aja jooksul,
Wordpressi ja tema pluginate eri versioonide lõikes,
muutub, aga avalikku API-t üirtatakse hoida konstantsena
isegi siis, kui andmebaasi formaati muudetakse.

https://docs.woocommerce.com/document/woocommerce-rest-api/

https://developer.wordpress.com/docs/api/

Seejärel palun kirjutage oma enda PHP-fail, mis
genereerib HTML'i, kus on tooted jaotatud täpselt nii,
nagu Teile meeldib, kuid see toodete nimekirja koostav PHP-fail
tohib toodete kohta infot saada AINULT TEIE ENDA KIRJUTATUD
PHP-klassi meetodeid kutsudes, ILMA, ET AINSATKI KUTSET
WORDPRESSI KOODI OTSE TEOSTAKS.

Kokkuvõtvalt on Teie rakenduses kihid sellised:

==================================
kõige_pealmine_kiht_ehk_teie_toodete_nimekiri.php
----------------------------------
teie_loodud_mähisklass.php
----------------------------------
<woocommerce ja Wordpressi PHP>
----------------------------------
<Kõige alumine kiht ehk andmebaasimootor/MySQL/PostgreSQL/SQLite/midaiganes_muud>
==================================

"teie_loodud_mähisklass.php" võlu seisneb selles, et
kui WordPressi või Woocommerce avalik API muutub, siis
Tuleb Teil vaid

teie_loodud_mähisklass.php

ära uuendada ja faili

kõige_pealmine_kiht_ehk_teie_toodete_nimekiri.php

ei pea Te ainsatki muudatust/uuendust tegema,
sõltumata sellest, kui töömahukas ja suur see fail on.
Olukord on lausa selline, et fail
ja faili

kõige_pealmine_kiht_ehk_teie_toodete_nimekiri.php

ei tule Teil muuta isegi siis, kui vahetate
Wordpressi Woocommerce plugina hoopis mõne muu
plugina vastu välja või vahetate lausa Wordpressi
koos kõigi oma pluginatega millegi muu vastu, sest
Wordpressi ja Woocommerce'ga suhtleb vaid

teie_loodud_mähisklass.php

Failis

kõige_pealmine_kiht_ehk_teie_toodete_nimekiri.php

Võite tooted linkida tavalisele Wordpressi tootelehele/tootevaatele.

Eelnevalt mainitud Wordpressi ja Woocommerce avaliku API kasutamine
tagab selle, et kui Wordpress või Woocommerce vahetavad
oma andmebaasiformaati, siis Te avaliku API
mittemuutumise korral ei pea oma mähiskihti,

teie_loodud_mähisklass.php

muutma, saades sedasi vabalt Wordpressi ja Woocommerce
versiooniuuendusi teha ilma, et versiooniuuendusega
kaasneks vajadus Teie loodud koodi uuendada.


Tänan lugemast.

Lisaküsimused on teretulnud.

RE: Woocommerce kategooriate koodamine ühele lehele
Postitaja: Wordpressikas 2017-08-31 11:53:47
TSITEERITUD:

Teile tõenäoliselt minu praegune vastus ei meeldi, aga
eks ma siis olen ikkagi see halbade uudiste üle andja:
MIDA IGANES TE KA VALMIS TEETE, ÜKSKÕIK KUI KAVALALT
JA TOREDALT, LAKKAB TOIMIMAST HETKEL, MIL SELLE WOOCOMMERCE
KOOD MÕNE WOOCOMMERCE UUE VERSIOONI KASUTUSELEVÕTUL MUUTUB.

.....



Miks ei meeldi? Ma küll alles õpin Wordpressi tundma ja selline info on igati väärtuslik. Küll ei saa ma norijatest aru aga see selleks. Enda kiitmiseks võin ära mainida, et olen programmeerinud Erply ja Woocommerce'i vahelise silla, mis toimib kahes suunas. Hetkel on üle elanud päris mitu uuendust, kuid Sinu tekst pani mind mõtlema ja hakkan vaikselt uuenduse kallal nokitsema.

Aga mitte sellest ei tahtnud ma lobiseda, vaid ikka oma murest.

Jõudsin siis lõpuks debug-imisega nii kaugele, et sain aru, et Wordpress ja Woocommerce võimaldavad ka urlist erinevate kategooriate liitmist ühele lehele. Mida aga ei võimalda minu teema. Kuna teema looja pole veel vastavaid uuendusi loonud siis tuleb ikkagi omal midagi välja mõelda.


MIda ma siis tegin, muutsin oma teema /woocommerce/archive-product.php nimetuse ja asendasin woocommerce originaal archive-product.php failiga. Nii saingi teada, et viga teema failis. Lõin uue faili aga ei tea nüüd, kuidas seda oma funktsiooni sisse laadida. Erinevaid variante proovisin, aga nendega lisas praeguse teema faili alla uee, ehk ta siis ei asendanud. taxonomy templiidiga kategooria vaateid muuta on lebo, kuid kuna ma soovin luua nö fiktiivse kategooria, mille alla koondan erinevate kategooriate tooted, siis taxonomy templiidi lahendus ei toimi

Soovitusi?

RE: Woocommerce kategooriate koodamine ühele lehele
Postitaja: progreja_keda_HR_osakonnad_r2mpsuks_peavad 2017-09-01 02:37:06
TSITEERITUD:

Miks ei meeldi? Ma küll alles õpin Wordpressi tundma ja
selline info on igati väärtuslik.
...
kuid Sinu tekst pani mind mõtlema ja hakkan vaikselt uuenduse kallal nokitsema.


Tänan komplimendieest :-)

TSITEERITUD:

...
taxonomy templiidiga kategooria vaateid muuta on lebo,
kuid kuna ma soovin luua nö fiktiivse kategooria,
mille alla koondan erinevate kategooriate tooted,
siis taxonomy templiidi lahendus ei toimi

Soovitusi?


Tunnistan, et ega ma ise samuti Wordpress'i
ega Woocommerce'i tunne. Olen küll
aastaid PHP-s tarkvara arendanud, viisil, et
paar aastat oli PHP mu üheks peamiseks
programmeerimiskeeleks, aga see oli hästi ammu
ja Woocommerce'ist kuulsin/lugesin elus esimest
korda alles Teie postitusest. Seega, ma
ei ole piisavalt tark, et konkreetselt
Wordpressi'i ja Woocommerce'i realisatsiooni
küsimustes kaasa rääkida/kirjutada.

Teisest küljest, Teie postituse põhjal
oletan, et Teil on infosüsteemis kirjeldatud
tooted mingite gruppide,
matemaatikast mõistes "ilma ühisosata" hulkade,
vahel ära jaotatud, stiilis, loomad, transpordivahendid, toiduained,
ning siis on mingi visualiseerimis-kood "theme", "template",
mille abil genereeritakse lõplik HTML või HTML'i ja JavaScript'i
segu, mille abil neid tooteid hulkade, "toote-kategooriate",
kaupa kuvatakse.

Ma ei ole kindel, et ma praegu üldse teemasse räägin/kirjutan,
aga igaks juhuks panen siia kirja mõned üldised
tähelepanekud, sest kui Te neid tähelepanekuid arvesse
ei võta, siis raiskate tõenäoliselt kõvasti mõttetule,
minemavisatavale, tööle oma tööaega.

Esimene üldine tähelepanek on, et tegelikult
ei ole võimalik kõike puu-kujulisse andmestruktuuri
liigitada. Näiteks, kui puu lehtedeks on
"loomad", "transpordivahendid", "toiduained", siis
hobune liigitub mitmesse kategooriasse korraga.
Hobune on loom, hobune on transpordivahend ja
hobune võib olla ka söök ehk toiduaine. Lahenduseks
on, et selle asemel, et hobust kindlalt ühte
kolmest liigitada, kasutatakse liigitamise asemel
märgendeid ehk silte ja üks ja sama liigitatav
asi võib omada rohkem kui ühte silti.
Sildistamise/märgendamise ("labeling") näiteid:

hobune:
loomad, transpordivahendid, toiduained

elevant:
loomad, transpordivahendid

kass:
loomad

auto:
transpordivahendid

lennuk:
transpordivahendid

nisujahu:
toiduained

Teie näite korral Teie poolt loodav
toodete "virtuaalkategooria" on lihtsalt
üks uus silt/märgend. Näiteks, kui
Teil on tooted

kass, hobune, elevant, auto, lennuk, nisujahu

ja Te loote oma enda uue "virtuaalkategooria", siis
see on samaväärne uue sildi/märgendi loomisega,
näiteks märgend "üle_20kg_massiga_nähtused", ning
kõigi olemasolevate toodete korral vaadatakse üle,
et kas ta väärib lisaks muudele, olemasolevatele,
märgenditele ka toda uut märgendit. Antud juhul on
uue märgendi lisamise järgselt olukord selline:


hobune:
loomad, transpordivahendid, toiduained,
üle_20kg_massiga_nähtused

elevant:
loomad, transpordivahendid, üle_20kg_massiga_nähtused

kass:
loomad

auto:
transpordivahendid, üle_20kg_massiga_nähtused

lennuk:
transpordivahendid, üle_20kg_massiga_nähtused

nisujahu:
toiduained,
<aga siin tekib uue märgendi lisamisel UUS PROBLEEM>


Kõik uued märgendid kõigile toodetele ei sobi. Näiteks
toode "nisujahu" võib olla massiga üks jahu-tera kuni
massiga mitu laevatäit, kuid sellise olukorraga saab
toime tulla lisa-märgendi abil. Kui lisaks märgendile

"üle_20kg_massiga_nähtused"

võtta kasutusele märgend

"üle_20kg_massiga_nähtused_mitte_määratav"

siis saab toode "nisujahu" sama hindamis-tegevuse
käigus, kus uuritakse, kas tootele saab lisada
märgendi

"üle_20kg_massiga_nähtused"

hoopis märgendi

"üle_20kg_massiga_nähtused_mitte_määratav"

Juhin tähelepanu, et too veider kirjapilt

inimene_nimi_eesnimi
inimene_nimi_perekonnanimi
inimene_vanus_bioloogiline
inimene_vanus_vaimne
inimene_load_autoload_A
inimene_load_autoload_B
inimene_load_autoload_C
inimene_load_autoload_D

kajastab rada puu juurest puu lehte. Antud nähtuse korral
on puuks/kataloogisüsteemi_analoogiks

inimene
_|
_+--nimi
_|___|
_|___+--eesnimi
_|___|
_|___+--perekonnanimi
|
+--vanus
_|___|
_|___+--bioloogiline
_|___|
_|___+--vaimne
|
+--load
_|___|
_|___+--autoload
_|___|___|
_|___|___+--A
_|___|___|
_|___|___+--B
_|___|___|
_|___|___+--C
_|___|___|
_|___|___+--D


Selline süsteemi järgi on programmi koodis
hästi praktiline muutujaid nimetada. Seda
kodeerimisvormi võib kombineerida veel niiöelda
Ungari kodeeringuga, kus muutuja nimele lisatakse
muutuja tüüpi kajastav prefiks. Näiteks

i_n2idist2isarv
ar_n2idismassiiv
ht_n2idispaisktabel
fd_n2idisujukomaarv

s_n2idisstring_inimene_nimi_eesnimi
s_n2idisstring_inimene_nimi_perekonnanimi

https://en.wikipedia.org/wiki/Hungarian_notation


Tüüpiliselt kiputakse infosüsteemide loomisel tegema viga,
et infosüsteemi arhitektuur pannakse toetama
vaid andmete puu lehtedesse klassifitseerimist, mitte
märgendamist. Teie võite enda korduvkasutatava koodi
luua kohe märgendamispõhise, nõnda, et puusse klassifitseerimine
on vaid märgendamise erijuht, toetatud märgendamispõhise
süsteemi poolt möödaminnes, iseenesest. See, kui Wordpress
ja Woocommerce on vigased, toetades toodete vaid puu lehtedesse
klassifitseerimist, ei ole Teie enda loodavale, universaalsemale,
koodile takistuseks.


-----------Uue--alamteema--algus---------------------------

Teine, täiesti eraldi teema, on kasutajaliideste teema.
Lühidalt öeldes, arhitektuuriliselt tasub tarkvara
kohe lüüa kahte ossa: andmete juurdepääsuõigusi järgiv
ja kalkulatsioone tegev serveri osa ning graafilise kasutajaliidese
osa. Täpsema ülevaate, mida soovitan sõltumata Robert Martin'i
kohati hooplevast stiilist ja esialgu teemavälisena näivast
jutust lõpuni vaadata, saab videost:

https://youtu.be/HhNIttd87xs?t=12m50s

Antud video üheks sõnumiks on, et tarkvaraarhitektuuri
korral tasub arhitektuur luua võimalikult sellisena, et
tarkvara realisatsiooni komponentide valikut saab
tarkvaraarenduse võimalikult hilises staadiumis muuta,
ilma, et tuleks seni tehtud koodi oluliselt
muutma/uuendama hakata. Ideaalis peaks sõltuvuskomponentide
valikud olema tagasipööratavad, niiöelda
pöördfunktsioonilaadsed.

Üheks võtteks, mida seal videos ei käsitleta, aga
mis on hästi praktiline, on kasutada arendusmustrit,
kus töömahukam või ka kiiruskriitilisem osa tarkvarast
on kirjutatud konsoolirakendusena, ükskõik mis muus
programmeerimiskeeles, ning siis selle asemel, et
hakata PHP-ga maadlema, võib PHP-skript tööle tõmmata
konsooliprogrammi

http://php.net/manual/en/function.exec.php

ning kasutada konsooliprogrammi poolt mõnda tekstifaili
kirjutatud XML/YAML/JSON/jne. andmeid kas edasiseks,
arvutuslikult kergemat sorti töötluseks, või ka otse
"echo" programmiga väljastamiseks. Sedasi on
võimalik PHP kaudu serveerivas veebitarkvaras
korduvkasutada teistes programmeerimiskeeltes loodud
tarkvara-komponente. Kui mõne tarkvara-komponendi
alglaadimine, näiteks Java programmi käivitumine,
võtab kaua aega, siis võib Java programm toimida
serverina taustal, kasutades näiteks failisüsteemi
raja kaudu määratud

http://www.linuxjournal.com/content/using-named-pipes-fifos-

ning PHP-programm võib tolle serveriga kas otse suhelda,
failikirjutamis-funktsioonide kaudu, või tõmmata
tööle mõne hästi väikese, kiirelt käivituva, programmi,
mis siis tolle Java programmiga suhtleb. Kui odavamad
veebimajutuskontod programmide püsivat käivutamist ei
võimalda, siis võib eri majutusteenuste pakkujate
teenuseid kombineerida, tehes nõnda, et töökindlat
PHP majutust pakkuva majutaja juures tõmmatakse tööle
väike konsooliprogramm, mis küsib andmmeid, krüptitult,
teise majutusteenuse pakkuja juures pidevalt jooksva
programmi käest. Selline lahendus ei sobi kiirete
lehtede serveerimiseks, sest võrgul on alati viited,
aga ärirakenduste taustatöötluseks sobib see suurepäraselt.
Ainuke reegel on, et majutajaid tuleb otsida ainult eestist
ja endistest NSV-Liidu osariikidest, sest Läänes on
majutusteenused ropp-kallid ja räigelt tsenseeritud.
Kusjuures, ma ei mõtle tsensuuri all pelgalt
porno ja Tor'i tsensuuri, vaid ma mõtlen tsensuuri
all olukorda, kus Lääne majutaja reklaamib, et
tulge aga meilt virtuaal-privaat-serverit rentima
ja siis paneb tuimalt serveri kinni põhjendusel, et
klient tarbis serveri ressursse majutaja poolt välja
reklaamitud piire täielikult ära kasutades. Seda nii
USA-s kui Lääne-Euroopas kui ka Saksamaal. Rootsi ja
Soome majutajate kohta ma ei oska öelda, kuid
Rootsi on üldiselt eestist suure viitega internetiühendus,
seega rootsi pakkujad põruvad juba ühenduse-viite pärast.
Mitte keskmise ühendus-kiiruse pärast, vaid just
ühenduse käivitus-viite, "ping-viite", pärast.


Ja ongi nii toodete klassifitseerimis-matemaatika,
kodeerimise ABC, serveri ja GUI lahku löömise idee
ja serveri tarkvara komponentideks jaotamise idee
lahti seletatud. Tänan lugemast :-D

P.S. Kui PHP's ja JavaScript'is koodi kirjutate,
siis palun kasutage võimalust mööda
peterburi venelaste poolt arendatavat PhpStorm-nimelist IDE't,
ilma, et sellega otse kuhigi kontosse sisse logiks.

https://www.jetbrains.com/phpstorm/

Teiseks, kui Te veel ei oska 10-sõrme-süsteemi, siis
kindlasti õppige see ära. See on õpitav vaid paari
nädalaga ja on eelduseks, et Te saaksite hiljem
erinevaid IDE-sid kasutades hakata samm-sammult
kasutama Vim'i klahvikombinatsioone. Vim'i
klahvikombinatsioone toetavad absoluutselt kõik
korralimumad IDE-d, kui mitte "otse", siis mingi
plugina abil. Microsoft Visual Studio ja Eclipse
kaasa arvatud.

Originaalvim, mida IDE-des matkitakse:

https://vim.sourceforge.io/

Flash-põhine, tasuta, heliga, õppekeskkond on
küll seoses Flash'i kasutamisega tüütult käivitatav,
aga ta on metoodiliselt oluliselt parem kui mitmed
teised tasuta või ka tasu eest müüdavad analoogid:

http://www.doorwayonline.org.uk/typing/texttype2/

Iga päev paar tundi harjutades on 10-sõrmesüsteem
õpitav umbes 2 nädalaga, natuke lõdvemalt õppides
umbes kuuga. 10-sõrmesüsteemi valdamise üheks
ülimalt suureks eeliseks on mitte nii väga
kirjutamiskiirus, kui e-post ja foorumipostitused
välja arvata, kuivõrd just ergonoomika, et saab
klaviatuuri vaateväljalt ära panna. Teine
10-sõrmesüsteemi oskamise suur võit on tähelepanu
hajumise vähenemine. Päris tobe oleks, kui kirjandit
kirjutades tuleks kirjandi sisu peale mõtlemise asemel
mõelda, kuidas pastakaga toime tulla. Sama kodeerides:
mõttepausid võtavad küll enamuse ajast, aga
koodi sisu üle mõtlemiseks on vaja tähelepanu
hoida koodi teemal, ilma, et tähelepanu klaviatuuri
kasutamisele hajuks.


Loodetavasti sain abiks olla :-)


Leheküljed: 1

©2002-2013 Martin Rebane & PHP.ee kaasautorid
  0.51545882225