Stanislavas Šašalevičius
Atėjo laikas, kai verslo savininkams nereikia aiškinti, kam jiems reikalinga svetainė ar internetinė parduotuvė. Dabar jie patys jį įsisavina verslo kūrimo etape. Pats laikas paaiškinti klientui: ką TVS ar platforma labiau tinka jo verslui? Ir daug sunkiau tai paaiškinti, kai klientas jau turi projektą savo platformoje, tada įtikinti jį būtinybe pereiti prie kitos platformos yra labai sunki užduotis. Bet, mūsų nuomone, su platforma 1C-Bitrixšią užduotį išspręsti daug lengviau nei su kitomis elektroninė prekyba platformos.
Todėl kviečiame susimąstyti 10 priežasčių kodėl reikia pereiti prie 1C-Bitrix.
1. 1C integracija
Tai vienas maloniausių 1C-Bitrix platformos „gėrybių“. 2007 metais Bitrixįsteigė bendrą įmonę su "1C" – „1C-Bitrix“. Mūsų nuomone, būtent šis faktas lėmė aktyvią šios platformos plėtrą. Atėjo nauja era, kai 1C integracija iš sudėtingos užduoties virto aiškia paprastų veiksmų schema.
Internete galite rasti „siaubo istorijų“, kuriose integracija į „Bitrix“ pristatoma kaip kažkas sudėtingo ir brangaus. Tiesą sakant, tokias „siaubo istorijas“ sugalvoja tie, kurie nelabai žino visų integracijos ir paties 1C niuansų. Integravimo problemos gali kilti tik šiais atvejais:
- Svetainės šablonas buvo sukurtas nesuvokiant funkcijų 1C integracija
- Pats 1C jau gerai nupjautas
- Žema kūrėjų kvalifikacija
O kaip savo nekaltumo įrodymą pateikiame vaizdo įrašą, kuriame mūsų ekspertai parodo, kaip tai padaryti integracija su1CTik už30 minučių. Ir jokių gudrybių. Tik faktai!
2. CRM integracija
Jeigu 1C integracija nieko nebestebina ir tai yra privaloma bet kurio funkcija elektroninė prekyba sistemos, tada CRM integracija tik įgauna pagreitį. Bet ir čia Bitrix bando būti priekyje visų.
Dėžėje 1C-Bitrix jau yra standartinė duomenų sinchronizavimo funkcija CRM Bitrix24. Tai leidžia pardavimų komandai efektyviau dirbti su potencialiais klientais, pasiūlymais ir naujais kontaktais. Iš karto iš dėžutės gausite paruoštą pardavimo įrankį.
Šiuo metu labai aktuali tema, kuri, be to, yra pagrindinis argumentas, kodėl projektas perkeliamas Bitrix jau 2017 m.
NUO 2017 m. vasario 1 d metų kasos aparatai turėtų siųsti elektroninės versijosčekius fiskalinių duomenų operatoriui – naujos taisyklės nustatomos m 54-FZ, 2 straipsnio 2 dalis.
Įstatymas įsigalios visiškai 2017 m. liepos 1 d. Kiekviena internetinė parduotuvė turi turėti Bankomatas(KKT), prijungtas prie interneto ir prijungtas prie fiskalinių duomenų operatoriaus (OFD).
Ką tai reiškia? Jeigu paprastais žodžiais, tada su 2017 m. liepos 1 d metų už kiekvieną užsakymą, apmokėtą internetu (ne pagal sąskaitą faktūrą) per jūsų internetinę parduotuvę, turite išmušti KKM patikrinimas, įtraukite į svetainės duomenų bazę, išsiųskite į elektroniniu formatu pirkėjo, ir net daug duomenų nedelsiant pateikti mokesčių inspekcijai. Ir visa tai užima viską 5 minutės kitaip gausi baudą.
Kaip jums patinka ši problema? Mūsų nuomone, tai labai nereikšminga. Kas mums patinka Bitrix yra tai, kad ji greitai reaguoja į visus rinkos pokyčius. Jis nesigilina į savo gaminio idealizavimą, o tiesiog matuoja visų komponentų pulsą elektroninė prekyba ir iš karto reaguoja.
Čia ir čia 1C-Bitrix operatyviai sureagavo ir iš karto įdiegė visus reikalavimus atitinkantį funkcionalumą 54-FZ. Kiek mums žinoma, šiuo metu „Bitrix“ bando nuorodą savo svetainėje: internetinė parduotuvė – kasos aparatas – mokesčių inspekcija. Todėl į liepos 1 d būsime visiškai ginkluoti Bitrix.
Manome, kad tai yra labai svarus argumentas perkelti projektą į platformą 1C-Bitrix tiksliai ties 2017 m- visiškas atitikimas 54-FZ. Manome, kad dėl to kils problemų daugeliui mokamų elektroninė prekyba platformų, jau nekalbant apie nemokamas. Verslo savininkas tiesiog turės atkreipti dėmesį 1C-Bitrix norėdami saugiai išspręsti problemą 54-FZ.
4. Marketingo įrankiai
Visi esame girdėję apie rinkodaros įgūdžius. 1C-Bitrix. Kažkas tyliai pavydėdamas sako, kad tai yra pagrindinis šios įmonės sėkmės komponentas. Bet nepavydėkime, o tiesiog pasimokykime iš patirties Bitrix. Laimei, pati įmonė 1C-Bitrix mielai dalijasi visais savo įrankiais tiesiai pačioje platformoje.
Dabar mes jums papasakosime apie įdomiausius, kaip mums atrodo, rinkodaros įrankiai, kuris pridės taškų už sprendimą perkelti projektą į Bitrix:
- pašto rinkodara. Leis jums dirbti su klientais automatiniu režimu per pašto adresų sąrašus. Jau paruošti scenarijai aktyvuojančių el. laiškų grandinėms skatina klientą grįžti į svetainę ir pateikti naujus užsakymus.
- Prekių rinkodara. Klientų motyvavimas akcijomis ir nuolaidomis visada turėjo teigiamą poveikį. Bitrix siūlo lanksčias konfigūravimo parinktis, kad būtų galima paveikti kiekvieną vartotojų grupę.
5. SEO įrankiai
SEO– buvo, yra ir bus svarbi priemonė pritraukti lankytojų į svetainę. Mes, kaip savo kūrėjai SEO sprendimus, tam skiriame ypatingą dėmesį.Deja, iki 2013 m SEO platformos komponentas 1C-Bitrix buvo labai neišsivysčiusi. Nebuvo įmanoma lanksčiai generuoti įprastų metažymų, jau nekalbant apie sudėtingesnes užduotis. Bet nuo 14 versijos Bitrix viskas pasikeitė. Dabar SEO platformos įrankiai apima:
- Meta žymų šablonai
- Išmaniosios svetainės schemos generavimas
- Robots.txt generavimas
- Siuntimas unikalus tekstasį „Yandex
- Ir daug daugiau
dideli duomenys– dabar tai ne tik madinga, bet ir reikalinga. Pirkėjas nebevertės vien pasiūlymo įsigyti prekes internetinėje parduotuvėje. Pirkėjas įvertins, jei parduotuvė pasiūlys būtent tai, ko jam reikia. Tam šios paslaugos skirtos.
Įmonė Bitrix ir operatyviai sureagavo šia kryptimi ir pradėjo savo debesijos paslaugą „1C-Bitrix BigData“. Tai leidžia klientui teikti asmeninius pasiūlymus, tai yra pagal tam tikrus algoritmus išanalizavus jo elgesio veiksmus, pasiūlyti jam reikalingas prekes. Asmeninės prekės gali būti atšauktos tiek viešoje svetainės dalyje, tiek adresų sąrašuose.
Atkreipkite dėmesį, kad panaši paslauga iš Bitrix ne tik padidins jūsų pardavimus, bet ir turės teigiamos įtakos didinant lojalumą jūsų internetinei parduotuvei.
7. Partnerių tinklas
Partnerių tinklas skatina jį augti 1C-Bitrix. Dabar tinkle yra daugiau nei 13 000 partnerių. Ir kasdien jų daugėja.
Ką verslui duoda toks platus tinklas?
Pirma, jūs gaunate galimybę pasirinkti kūrėją pagal šiuos parametrus:
- Projekto biudžetas
- Kūrėjo kvalifikacija ir kompetencija
- Regioniškumas
Kalbant apie tiesioginio partnerio pasirinkimą, mūsų nuomone, tai yra pats svarbiausias ir atsakingiausias etapas. Nuo jo priklauso, kaip seksis jūsų projektas. Bitrix, žinoma, bando kažkaip filtruoti ir rasti jums tinkamus kūrėjus, bet, kaip manome, kol kas tai ne visada pavykdavo. Ta pati būsena „Auksinis partneris“ nesuteikia jokių garantijų jūsų projektui. Juk, kaip manome, įstojimo riba šiam statusui gauti yra per žema ir vertėtų ją kelti.
Nors tai nėra šio straipsnio tema, vis dėlto, remdamiesi tuo, kas išdėstyta pirmiau, galime pateikti keletą rekomendacijų:
- Partnerių atvejai. Atidžiai susipažinkite su kūrėjo jau įgyvendintais projektais, panašiais į jūsų. Užduokite aiškinamuosius klausimus apie bylas. Nebūk drovus.
- Ekspertizė. Būtinai patikrinkite partnerio kvalifikaciją. Bandymas prasideda nuo pirmojo prisilietimo. Kompetentingais patikslinančiais klausimais partneris atskleis jūsų projektą, o įtikinamais atsakymais į klausimus išskirs visas jūsų abejones.
8. Elektroninės prekybos platforma Nr. 1
Paradoksalu, bet tai yra paprasčiausias ir svarbiausias argumentas, paneigiantis perėjimą prie Bitrix.
Iš grafiko matyti, kad apie 60% rinkos komercinis TVS dabar užima įmonė 1C-Bitrix. Ir vargu ar 6 iš 10 klysta. Jie pasirinko atidžiai išanalizavę visus produkto privalumus ir trūkumus. Dabar sekdami jų pavyzdžiu jums daug lengviau priimti teisingą sprendimą.
Norėčiau palinkėti Bitrix kad ties tuo nesustotų ir stengtųsi ne tik išlaikyti esamą rinkos dalį, bet ir ją padidinti. Ir yra kur augti: 40% komercinės TVS + rinkos nemokamos sistemos. 1C-Bitrix tiesiog privalote sukurti tokias sąlygas ir tokią platformą, į kurią tiesiog norite pereiti.
9. 1C-Bitrix.Marketplace
Geriausius nusprendėme pasilikti vėlesniam laikui. Savo pardavimo platformos kūrimas Turgavietė 2011 m. atidarytas anksčiau 1C-Bitrix naujų galimybių. Juk šio žingsnio dėka populiarinimas Bitrix išaugo tiek tarp kūrėjų, tiek tiesiogiai tarp pardavimų internetu dalyvių. Ir tam yra keletas priežasčių:
- Tipiški sprendimai – Greita pardavimo pradžia. Po paleidimo 1 NUO-Bitrix.Marketplace buvo didelis standartinių šablonų sprendimų bumas. Dėl to klientai tikrai atidarė internetines parduotuves nuo kelių dienų iki savaičių, o ne daug mėnesių ir brangių projektų nuo nulio. Tai leido jiems greitai įgyti internetinių pardavimų patirties ir sąmoningiau bei profesionaliau žiūrėti į savo projekto vystymą.
- 1C-Bitrix funkcionalumo didinimas. Dabar ko jis negali padaryti pats Bitrix yra pagaminti jo partnerių. Tai išplečia platformos galimybes ir daro jas beveik neribotas.
- Kūrėjų kvalifikacijos kėlimas.Svetainė atvėrė naujas galimybes tiesiogiai atlikėjams. Taigi tai prisidėjo prie techninių specialistų kvalifikacijos augimo kuriant sprendimus 1C-Bitrix.
10. Nuolatinis tobulinimas ir atnaujinimai
Kaip paminėta aukščiau, 1C-Bitrix atidžiai stebi visas tendencijas ir pokyčius elektroninė prekyba turgus. Gauni ne tik šiai dienai aktualią prekę, kaip nutinka su paties raštu TVS– Jūs gaunate nuolat besikeičiančią platformą.
Kai gausite metų nemokamų naujinimų. Tai reiškia, kad per šį laiką jūsų projektas visada bus atnaujintas. Ir jei perkate 1C-Bitrix produktus per mus, taip pat gausite 20% užsakymo sumos premijas, kurias galite išleisti pirkdami mūsų modulius.
Norėčiau pažymėti, kad Bitrix yra tam tikra taisyklė, kuri jau yra ilgam laikui nesugadintas: du visuotiniai naujinimai per metus. Tai reiškia, kad konkrečios šių atnaujinimų įgyvendinimo datos ir terminai jau yra nustatyti iš anksto. Nurodytomis datomis atliekamas laidos pristatymas, o iškart po to – sistemingas jo įgyvendinimas. Šis darbo modelis yra labai efektyvus. Tai motyvuoja plėtros skyrių atsikratyti kodo idealizavimo ir padeda greitai pateikti rezultatus tiesiai internetinės parduotuvės savininkui.
Čia, atrodo, galime sustoti. Iš viso 10 priežasčių bet kiekviena priežastis Bitrix"kentėjo". Kiekviena priežastis atlaikė laiko išbandymą, nesėkmingus eksperimentus, nepavykusias hipotezes. Tikimės, kad 1C-Bitrix suteiks mums naujų priežasčių dirbti šioje konkrečioje platformoje.
Visą savo darbo su Bitrix laiką turėjau galimybę dirbti su labai daugybe projektų, kuriuos kažkas sukūrė prieš mane. Čia pateikiami nedideli patobulinimai, įvairių klaidų ir logikos veikimo klaidų taisymas, svetainės pertvarkymas ir globalūs esamų funkcijų pakeitimai. Ir, kaip ir bet kuris kitas kūrėjas, nekenčiu rūšiuoti kitų žmonių šiukšlių, ramentų ir „laikinų“ lopų, kurie iš tikrųjų prisimena 8-ąjį produkto leidimą.
Čia pasistengsiu nekreipti dėmesio į standartines „blogiausias praktikas“ programuojant PHP, pvz., nekreipti dėmesio į kintamųjų ir funkcijų pavadinimų pasirinkimą, nereikalingas duomenų bazės užklausas cikle, vartotojo duomenų patvirtinimo stoką. formų, komentarų ignoravimo ir panašiai. Pabandysiu tiksliai paliesti akimirkas, būdingas „Bitrix“ plėtrai, o tai vėliau leis jums išvengti programuotojo, kuris turėjo palydėti jūsų kodą, pasipiktinimo ir keiksmų prieš jus. Ir taip, dažnai jūs pats pasirodysite šiuo programuotoju po metų ar daugiau, kai visiškai pamiršite, kodėl čia įkišote tą ar kitą ramentą.
„Rašykite kodą taip, lyg jį lydėtų smurtaujantis psichopatas, žinantis, kur tu gyveni“ (c) Johnas F. Woodsas
Pirma, ir, mano nuomone, svarbiausia – dėl Dievo meilės, naudokite vietinį aplanką. Tai tiesiog labai svarbu naudojant versijų valdymo sistemą – tereikia prie išimčių pridėti aplanką /bitrix/. Viskas. Be to, beveik visa plėtra vykdoma tik joje. Tai labai supaprastina vėliau reikalingų failų ir komponentų paiešką, padeda neužkimšti saugyklos nereikalingais failais ir apskritai - suteikia projekto medžiui tvarkingesnį, „žmogiškesnį“ vaizdą.
Nekeiskite branduolio. Net jei esate tikri, kad jis nebus atnaujintas. Net jei tai greičiau. Net jei esi tinginys. Pamiršk šią mintį kaip blogą sapną. Jei reikia pakeisti standartinio komponento logiką, perkelkite jį į naują vardų sritį /local/components/modify/ ir dirbkite su ja. Tas pats pasakytina apie modulius, programėles ir verslo procesų veiklą.
Neužterškite failo init.php. Sujunkite funkcijas, skirtas darbui su konkrečiu moduliu ar funkcijomis į klasę, įrašykite visą šią klasę į atskirą failą, o į init.php tiesiog įtraukite šiuos failus ir parašykite įvykių tvarkykles. Mačiau init.php failus po 500 Kb, kur funkcijos, pastovūs apibrėžimai, klasės ir tvarkyklių inicijavimas buvo sumaišyti į netvarką. Žinoma, kai teko susidurti su šiais failais, keikiau savo pirmtakus.
Kitas punktas netaikomas kūrimo atvejui paruoštus sprendimus Prekyvietėje, kai tikslas yra padaryti galutiniam vartotojui kuo labiau pritaikomą funkcionalumą iš viešosios dalies. Jei dirbate su konkrečiu projektu, konkrečiam TOR - neturėtumėte stengtis sukurti vieningo komponento šablono visoms progoms. Asmeniškai aš laikausi filosofijos – geriau turėti kelis paprastus įvairiems tikslams naudojamus šablonus, nei vieną universalų, bet kuriame vėliau koją susilaužys pats velnias. Žinoma, kiekvienu konkrečiu atveju reikia remtis tuo, kas yra – techninėmis užduotimis, įgyvendinimo galimybėmis ir panašiai, tačiau kai kurie „Occam's Razor“ naudoja pernelyg uoliai. Kaip pavyzdį pateiksiu vieną lizingo bendrovės projektą, kurį atsitiktinai redagavau. Pats projektas, žinoma, buvo įgyvendintas siaubingai, tikras siaubas buvo paslaugų katalogo skyriaus puslapiuose. Kiekviena iš penkių skyrių turėjo savo išdėstymą, kuris skyrėsi tiek blokų padėtimi puslapyje, tiek iš esmės kai kurių iš jų buvimu. Ir visiems penkiems puslapiams buvo naudojamas vienas šablonas su daugybe if-else, dubliuojančių komponentų iškvietimus, jungiančius stilius ir scenarijus, kurie, be to, periodiškai konfliktuodavo vienas su kitu. Rezultate – didžiulė byla, kurioje tarsi mirtis suprasti „be pusės litro“. Nors, atrodytų, kas sutrukdė pasidaryti 5 skirtingus šablonus ir nesudaryti sunkumų iš netikėtumo?
Naudokite API. Neišradinėk dviračio ten, kur jo nereikia. Pasinaudokite dokumentacija – visas produktas yra gana gerai aprašytas, taip pat kiekvieną funkciją galima išsamiai peržiūrėti bxapi.ru.
Venkite tiesioginių duomenų bazės užklausų. tai ypatinga byla ankstesnė pastraipa - naudokite API. Grubus, neapsaugotas užklausas gali sukelti duomenų sugadinimą, praradimą ar net pavojų.
Nenaudokite CNC komponentų iš svetainės šaknies. Pasekmės paprastai būna gana apgailėtinos, nes CNC naudoja adresų tvarkyklės failą, bandant jį naudoti iš šaknies, lengvai sulaužysite kitų komponentų adresus, taip pat 404 puslapius. Nieko nepakenks, jei jūsų straipsniai bus skirti aplankui /articles/, o produktai - /catalog/.
Įtraukite css ir js naudodami API. Iki šiol visur sutinku scenarijų ir stilių ryšį naudojant žymes
Visą savo darbo su Bitrix laiką turėjau galimybę dirbti su labai daugybe projektų, kuriuos kažkas sukūrė prieš mane. Čia pateikiami nedideli patobulinimai, įvairių klaidų ir logikos veikimo klaidų taisymas, svetainės pertvarkymas ir globalūs esamų funkcijų pakeitimai. Ir, kaip ir bet kuris kitas kūrėjas, nekenčiu rūšiuoti kitų žmonių šiukšlių, ramentų ir „laikinų“ lopų, kurie iš tikrųjų prisimena 8-ąjį produkto leidimą.
Čia pasistengsiu nekreipti dėmesio į standartines „blogiausias praktikas“ programuojant PHP, pvz., nekreipti dėmesio į kintamųjų ir funkcijų pavadinimų pasirinkimą, nereikalingas duomenų bazės užklausas cikle, vartotojo duomenų patvirtinimo stoką. formų, komentarų ignoravimo ir panašiai. Pabandysiu tiksliai paliesti akimirkas, būdingas „Bitrix“ plėtrai, o tai vėliau leis jums išvengti programuotojo, kuris turėjo palydėti jūsų kodą, pasipiktinimo ir keiksmų prieš jus. Ir taip, dažnai jūs pats pasirodysite šiuo programuotoju po metų ar daugiau, kai visiškai pamiršite, kodėl čia įkišote tą ar kitą ramentą.
„Rašykite kodą taip, lyg jį lydėtų smurtaujantis psichopatas, žinantis, kur tu gyveni“ (c) Johnas F. WoodsasPirma, ir, mano nuomone, svarbiausia – dėl Dievo meilės, naudokite vietinį aplanką. Tai tiesiog labai svarbu naudojant versijų valdymo sistemą – tereikia prie išimčių pridėti aplanką /bitrix/. Viskas. Be to, beveik visa plėtra vykdoma tik joje. Tai labai supaprastina vėliau reikalingų failų ir komponentų paiešką, padeda neužkimšti saugyklos nereikalingais failais ir apskritai - suteikia projekto medžiui tvarkingesnį, „žmogiškesnį“ vaizdą.
Nekeiskite branduolio. Net jei esate tikri, kad jis nebus atnaujintas. Net jei tai greičiau. Net jei esi tinginys. Pamiršk šią mintį kaip blogą sapną. Jei reikia pakeisti standartinio komponento logiką, perkelkite jį į naują vardų sritį /local/components/modify/ ir dirbkite su ja. Tas pats pasakytina apie modulius, programėles ir verslo procesų veiklą.
Neužterškite failo init.php. Sujunkite funkcijas, skirtas darbui su konkrečiu moduliu ar funkcijomis į klasę, įrašykite visą šią klasę į atskirą failą, o į init.php tiesiog įtraukite šiuos failus ir parašykite įvykių tvarkykles. Mačiau init.php failus po 500 Kb, kur funkcijos, pastovūs apibrėžimai, klasės ir tvarkyklių inicijavimas buvo sumaišyti į netvarką. Žinoma, kai teko susidurti su šiais failais, keikiau savo pirmtakus.
Kita pastraipa netaikoma tuo atveju, kai kuriami paruošti sprendimai Marketplace, kai siekiama galutiniam vartotojui padaryti kuo labiau pritaikomą funkcionalumą iš viešosios dalies. Jei dirbate su konkrečiu projektu, konkrečiam TOR - neturėtumėte stengtis sukurti vieningo komponento šablono visoms progoms. Asmeniškai aš laikausi filosofijos – geriau turėti kelis paprastus įvairiems tikslams naudojamus šablonus, nei vieną universalų, bet kuriame vėliau koją susilaužys pats velnias. Žinoma, kiekvienu konkrečiu atveju reikia remtis tuo, kas yra – techninėmis užduotimis, įgyvendinimo galimybėmis ir panašiai, tačiau vis tiek neturėtumėte pamiršti apie Occam's Razor. Kaip pavyzdį pateiksiu vieną lizingo bendrovės projektą, kurį atsitiktinai redagavau. Pats projektas, žinoma, buvo įgyvendintas siaubingai, tikras siaubas buvo paslaugų katalogo skyriaus puslapiuose. Kiekviena iš penkių skyrių turėjo savo išdėstymą, kuris skyrėsi tiek blokų padėtimi puslapyje, tiek iš esmės kai kurių iš jų buvimu. Ir visiems penkiems puslapiams buvo naudojamas vienas šablonas su daugybe if-else, dubliuojančių komponentų iškvietimus, jungiančius stilius ir scenarijus, kurie, be to, periodiškai konfliktuodavo vienas su kitu. Rezultate – didžiulė byla, kurioje tarsi mirtis suprasti „be pusės litro“. Nors, atrodytų, kas sutrukdė pasidaryti 5 skirtingus šablonus ir nesudaryti sunkumų iš netikėtumo?
Naudokite API. Neišradinėk dviračio ten, kur jo nereikia. Pasinaudokite dokumentacija – visas produktas yra gana gerai aprašytas, taip pat kiekvieną funkciją galima išsamiai peržiūrėti bxapi.ru.
Venkite tiesioginių duomenų bazės užklausų. Tai ypatingas ankstesnio punkto atvejis – naudokite API. Grubus, neapsaugotas užklausas gali sukelti duomenų sugadinimą, praradimą ar net pavojų.
Nenaudokite CNC komponentų iš svetainės šaknies. Pasekmės paprastai būna gana apgailėtinos, nes CNC naudoja adresų tvarkyklės failą, bandant jį naudoti iš šaknies, lengvai sulaužysite kitų komponentų adresus, taip pat 404 puslapius. Nieko nepakenks, jei jūsų straipsniai bus skirti aplankui /articles/, o produktai - /catalog/.
Įtraukite css ir js naudodami API. Iki šiol visur sutinku scenarijų ir stilių ryšį naudojant html žymas. Naudokite \Bitrix\Main\Page\Asset class objektą ir addJs() bei addCss() funkcijas. Tai leis sujungti failus ir vėliau juos išsaugoti talpykloje vienu spustelėjus žymimąjį laukelį pagrindinio modulio nustatymuose
Ir galiausiai, klaida susijusi ne tik su „Bitrix“, bet ir per dažnai pradėjau susidurti su su ja susijusiomis problemomis. Patikrinkite, ar nėra tuštumos masyvo su mėginių rezultatais. Pavyzdžiui, paskutinį kartą su šia problema susidūriau dirbdamas su viena internetine parduotuve. Skundas: puslapiai kartais įkeliami per 16 sekundžių. Su kuo tai susiję – neaišku. Bandymu ir klaidomis išsiaiškinau, kad puslapiai nepadoriai ilgai kraunasi tik tada, kai krepšelis tuščias. Atrodė, kodėl? Kaip paaiškėjo, užvedus pelės žymeklį virš krepšelio pasirodė iššokantis langas, kuriame buvo rodomi į krepšelį įdėtos prekės vaizdai. Taigi, ką padarė ankstesnis kūrėjas? Paėmiau komponento „mažas krepšelis“ darbo rezultatą ir faile result_modifier.php iškviečiau produktų GetList(), kad pasirinkčiau vaizdus su filtru iš produktų ID masyvo, tada pridėjau vaizdo src. nuo atrankos rezultatų iki atitinkamo produkto masyvo. Dėl to, kai krepšelyje nebuvo prekių, filtras ištuštėjo, o į pasirinkimą pateko VISAS prekių katalogas. Na, tada ciklas kiekvienam ir ... turime tai, ką turime. Akivaizdu, kad kūrimo etape su 15 bandomųjų gaminių tai buvo nepastebėta, o problemų iškilo jau kovinėmis sąlygomis. Nors, atrodytų, vertėjo patikrinti tuščią ($arResult[‘ITEMS’])…
Tai užbaigia mano asmeninę „blogiausią praktiką“, susijusią su „Bitrix“ kūrimu. Jei bent kažkam ši informacija padeda išvengti klaidų ateityje ir pagerinti savo tobulėjimo stilių, vadinasi, tai buvo ne veltui.
Galite padėti ir pervesti šiek tiek lėšų svetainės plėtrai
Visą savo darbo su Bitrix laiką turėjau galimybę dirbti su labai daugybe projektų, kuriuos kažkas sukūrė prieš mane. Čia pateikiami nedideli patobulinimai, įvairių klaidų ir logikos veikimo klaidų taisymas, svetainės pertvarkymas ir globalūs esamų funkcijų pakeitimai. Ir, kaip ir bet kuris kitas kūrėjas, nekenčiu rūšiuoti kitų žmonių šiukšlių, ramentų ir „laikinų“ lopų, kurie iš tikrųjų prisimena 8-ąjį produkto leidimą.
Čia pasistengsiu nekreipti dėmesio į standartines „blogiausias praktikas“ programuojant PHP, pvz., nekreipti dėmesio į kintamųjų ir funkcijų pavadinimų pasirinkimą, nereikalingas duomenų bazės užklausas cikle, vartotojo duomenų patvirtinimo stoką. formų, komentarų ignoravimo ir panašiai. Pabandysiu tiksliai paliesti akimirkas, būdingas „Bitrix“ plėtrai, o tai vėliau leis jums išvengti programuotojo, kuris turėjo palydėti jūsų kodą, pasipiktinimo ir keiksmų prieš jus. Ir taip, dažnai jūs pats pasirodysite šiuo programuotoju po metų ar daugiau, kai visiškai pamiršite, kodėl čia įkišote tą ar kitą ramentą.
„Rašykite kodą taip, lyg jį lydėtų smurtaujantis psichopatas, žinantis, kur tu gyveni“ (c) Johnas F. Woodsas
Pirma, ir, mano nuomone, svarbiausia – dėl Dievo meilės, naudokite vietinį aplanką. Tai tiesiog labai svarbu naudojant versijų valdymo sistemą – tereikia prie išimčių pridėti aplanką /bitrix/. Viskas. Be to, beveik visa plėtra vykdoma tik joje. Tai labai supaprastina vėliau reikalingų failų ir komponentų paiešką, padeda neužkimšti saugyklos nereikalingais failais ir apskritai - suteikia projekto medžiui tvarkingesnį, „žmogiškesnį“ vaizdą.
Nekeiskite branduolio. Net jei esate tikri, kad jis nebus atnaujintas. Net jei tai greičiau. Net jei esi tinginys. Pamiršk šią mintį kaip blogą sapną. Jei reikia pakeisti standartinio komponento logiką, perkelkite jį į naują vardų sritį /local/components/modify/ ir dirbkite su ja. Tas pats pasakytina apie modulius, programėles ir verslo procesų veiklą.
Neužterškite failo init.php. Sujunkite funkcijas, skirtas darbui su konkrečiu moduliu ar funkcijomis į klasę, įrašykite visą šią klasę į atskirą failą, o į init.php tiesiog įtraukite šiuos failus ir parašykite įvykių tvarkykles. Mačiau init.php failus po 500 Kb, kur funkcijos, pastovūs apibrėžimai, klasės ir tvarkyklių inicijavimas buvo sumaišyti į netvarką. Žinoma, kai teko susidurti su šiais failais, keikiau savo pirmtakus.
Kita pastraipa netaikoma tuo atveju, kai kuriami paruošti sprendimai Marketplace, kai siekiama galutiniam vartotojui padaryti kuo labiau pritaikomą funkcionalumą iš viešosios dalies. Jei dirbate su konkrečiu projektu, konkrečiam TOR - neturėtumėte stengtis sukurti vieningo komponento šablono visoms progoms. Asmeniškai aš laikausi filosofijos – geriau turėti kelis paprastus įvairiems tikslams naudojamus šablonus, nei vieną universalų, bet kuriame vėliau koją susilaužys pats velnias. Žinoma, kiekvienu konkrečiu atveju reikia remtis tuo, kas yra – techninėmis užduotimis, įgyvendinimo galimybėmis ir panašiai, tačiau vis tiek neturėtumėte pamiršti apie Occam's Razor. Kaip pavyzdį pateiksiu vieną lizingo bendrovės projektą, kurį atsitiktinai redagavau. Pats projektas, žinoma, buvo įgyvendintas siaubingai, tikras siaubas buvo paslaugų katalogo skyriaus puslapiuose. Kiekviena iš penkių skyrių turėjo savo išdėstymą, kuris skyrėsi tiek blokų padėtimi puslapyje, tiek iš esmės kai kurių iš jų buvimu. Ir visiems penkiems puslapiams buvo naudojamas vienas šablonas su daugybe if-else, dubliuojančių komponentų iškvietimus, jungiančius stilius ir scenarijus, kurie, be to, periodiškai konfliktuodavo vienas su kitu. Rezultate – didžiulė byla, kurioje tarsi mirtis suprasti „be pusės litro“. Nors, atrodytų, kas sutrukdė pasidaryti 5 skirtingus šablonus ir nesudaryti sunkumų iš netikėtumo?
Naudokite API. Neišradinėk dviračio ten, kur jo nereikia. Pasinaudokite dokumentacija – visas produktas yra gana gerai aprašytas, taip pat kiekvieną funkciją galima išsamiai peržiūrėti bxapi.ru.
Venkite tiesioginių duomenų bazės užklausų. Tai ypatingas ankstesnio punkto atvejis – naudokite API. Grubus, neapsaugotas užklausas gali sukelti duomenų sugadinimą, praradimą ar net pavojų.
Nenaudokite CNC komponentų iš svetainės šaknies. Pasekmės paprastai būna gana apgailėtinos, nes CNC naudoja adresų tvarkyklės failą, bandant jį naudoti iš šaknies, lengvai sulaužysite kitų komponentų adresus, taip pat 404 puslapius. Nieko nepakenks, jei jūsų straipsniai bus skirti aplankui /articles/, o produktai - /catalog/.
Įtraukite css ir js naudodami API. Iki šiol visur sutinku scenarijų ir stilių ryšį naudojant html žymas. Naudokite \Bitrix\Main\Page\Asset class objektą ir addJs() bei addCss() funkcijas. Tai leis sujungti failus ir vėliau juos išsaugoti talpykloje vienu spustelėjus žymimąjį laukelį pagrindinio modulio nustatymuose
Ir galiausiai, klaida susijusi ne tik su „Bitrix“, bet ir per dažnai pradėjau susidurti su su ja susijusiomis problemomis. Patikrinkite, ar nėra tuštumos masyvo su mėginių rezultatais. Pavyzdžiui, paskutinį kartą su šia problema susidūriau dirbdamas su viena internetine parduotuve. Skundas: puslapiai kartais įkeliami per 16 sekundžių. Su kuo tai susiję – neaišku. Bandymu ir klaidomis išsiaiškinau, kad puslapiai nepadoriai ilgai kraunasi tik tada, kai krepšelis tuščias. Atrodė, kodėl? Kaip paaiškėjo, užvedus pelės žymeklį virš krepšelio pasirodė iššokantis langas, kuriame buvo rodomi į krepšelį įdėtos prekės vaizdai. Taigi, ką padarė ankstesnis kūrėjas? Paėmiau komponento „mažas krepšelis“ darbo rezultatą ir faile result_modifier.php iškviečiau produktų GetList(), kad pasirinkčiau vaizdus su filtru iš produktų ID masyvo, tada pridėjau vaizdo src. nuo atrankos rezultatų iki atitinkamo produkto masyvo. Dėl to, kai krepšelyje nebuvo prekių, filtras ištuštėjo, o į pasirinkimą pateko VISAS prekių katalogas. Na, tada ciklas kiekvienam ir ... turime tai, ką turime. Akivaizdu, kad kūrimo etape su 15 bandomųjų gaminių tai buvo nepastebėta, o problemų iškilo jau kovinėmis sąlygomis. Nors, atrodytų, vertėjo patikrinti tuščią ($arResult[‘ITEMS’])…
Tai užbaigia mano asmeninę „blogiausią praktiką“, susijusią su „Bitrix“ kūrimu. Jei bent kažkam ši informacija padeda išvengti klaidų ateityje ir pagerinti savo tobulėjimo stilių, vadinasi, tai buvo ne veltui.
Visą savo darbo su Bitrix laiką turėjau galimybę dirbti su labai daugybe projektų, kuriuos kažkas sukūrė prieš mane. Čia pateikiami nedideli patobulinimai, įvairių klaidų ir logikos veikimo klaidų taisymas, svetainės pertvarkymas ir globalūs esamų funkcijų pakeitimai. Ir, kaip ir bet kuris kitas kūrėjas, nekenčiu rūšiuoti kitų žmonių šiukšlių, ramentų ir „laikinų“ lopų, kurie iš tikrųjų prisimena 8-ąjį produkto leidimą.
Čia pasistengsiu nekreipti dėmesio į standartines „blogiausias praktikas“ programuojant PHP, pvz., nekreipti dėmesio į kintamųjų ir funkcijų pavadinimų pasirinkimą, nereikalingas duomenų bazės užklausas cikle, vartotojo duomenų patvirtinimo stoką. formų, komentarų ignoravimo ir panašiai. Pabandysiu tiksliai paliesti akimirkas, būdingas „Bitrix“ plėtrai, o tai vėliau leis jums išvengti programuotojo, kuris turėjo palydėti jūsų kodą, pasipiktinimo ir keiksmų prieš jus. Ir taip, dažnai jūs pats pasirodysite šiuo programuotoju po metų ar daugiau, kai visiškai pamiršite, kodėl čia įkišote tą ar kitą ramentą.
„Rašykite kodą taip, lyg jį lydėtų smurtaujantis psichopatas, žinantis, kur tu gyveni.“ © John F. Woods
Pirma, ir, mano nuomone, svarbiausia – dėl Dievo meilės, naudokite vietinį aplanką. Tai tiesiog labai svarbu naudojant versijų valdymo sistemą – tereikia prie išimčių pridėti aplanką /bitrix/. Viskas. Be to, beveik visa plėtra vykdoma tik joje. Tai labai supaprastina vėliau reikalingų failų ir komponentų paiešką, padeda neužkimšti saugyklos nereikalingais failais ir apskritai - suteikia projekto medžiui tvarkingesnį, „žmogiškesnį“ vaizdą.
Nekeiskite branduolio. Net jei esate tikri, kad jis nebus atnaujintas. Net jei tai greičiau. Net jei esi tinginys. Pamiršk šią mintį kaip blogą sapną. Jei reikia pakeisti standartinio komponento logiką, perkelkite jį į naują vardų sritį /local/components/modify/ ir dirbkite su ja. Tas pats pasakytina apie modulius, programėles ir verslo procesų veiklą.
Neužterškite failo init.php. Sujunkite funkcijas, skirtas darbui su konkrečiu moduliu ar funkcijomis į klasę, įrašykite visą šią klasę į atskirą failą, o į init.php tiesiog įtraukite šiuos failus ir parašykite įvykių tvarkykles. Mačiau init.php failus po 500 Kb, kur funkcijos, pastovūs apibrėžimai, klasės ir tvarkyklių inicijavimas buvo sumaišyti į netvarką. Žinoma, kai teko susidurti su šiais failais, keikiau savo pirmtakus.
Kita pastraipa netaikoma tuo atveju, kai kuriami paruošti sprendimai Marketplace, kai siekiama galutiniam vartotojui padaryti kuo labiau pritaikomą funkcionalumą iš viešosios dalies. Jei dirbate su konkrečiu projektu, konkrečiam TOR - neturėtumėte stengtis sukurti vieningo komponento šablono visoms progoms. Asmeniškai aš laikausi filosofijos – geriau turėti kelis paprastus įvairiems tikslams naudojamus šablonus, nei vieną universalų, bet kuriame vėliau koją susilaužys pats velnias. Žinoma, kiekvienu konkrečiu atveju reikia remtis tuo, kas yra – techninėmis užduotimis, įgyvendinimo galimybėmis ir panašiai, tačiau vis tiek neturėtumėte pamiršti apie Occam's Razor. Kaip pavyzdį pateiksiu vieną lizingo bendrovės projektą, kurį atsitiktinai redagavau. Pats projektas, žinoma, buvo įgyvendintas siaubingai, tikras siaubas buvo paslaugų katalogo skyriaus puslapiuose. Kiekviena iš penkių skyrių turėjo savo išdėstymą, kuris skyrėsi tiek blokų padėtimi puslapyje, tiek iš esmės kai kurių iš jų buvimu. Ir visiems penkiems puslapiams buvo naudojamas vienas šablonas su daugybe if-else, dubliuojančių komponentų iškvietimus, jungiančius stilius ir scenarijus, kurie, be to, periodiškai konfliktuodavo vienas su kitu. Rezultatas – didžiulė byla, kurioje suprasti „be pusės litro“ buvo kaip mirtis. Nors, atrodytų, kas sutrukdė pasidaryti 5 skirtingus šablonus ir nesudaryti sunkumų iš netikėtumo?
Naudokite API. Neišradinėk dviračio ten, kur jo nereikia. Pasinaudokite dokumentacija – visas produktas yra gana gerai aprašytas, taip pat kiekvieną funkciją galima išsamiai peržiūrėti bxapi.ru.
Venkite tiesioginių duomenų bazės užklausų. Tai ypatingas ankstesnio punkto atvejis – naudokite API. Grubus, neapsaugotas užklausas gali sukelti duomenų sugadinimą, praradimą ar net pavojų.
Nenaudokite CNC komponentų iš svetainės šaknies. Pasekmės paprastai būna gana apgailėtinos, nes CNC naudoja adresų tvarkyklės failą, bandant jį naudoti iš šaknies, lengvai sulaužysite kitų komponentų adresus, taip pat 404 puslapius. Nieko nepakenks, jei jūsų straipsniai bus skirti aplankui /articles/, o produktai - /catalog/.
Įtraukite css ir js naudodami API. Iki šiol visur sutinku scenarijų ir stilių ryšį naudojant html žymas. Naudokite klasės objektą \Bitrix\Main\Page\Asset ir addJs() bei addCss() funkcijas. Tai leis sujungti failus ir vėliau juos išsaugoti talpykloje vienu spustelėjus žymimąjį laukelį pagrindinio modulio nustatymuose
Ir galiausiai, klaida susijusi ne tik su „Bitrix“, bet ir per dažnai pradėjau susidurti su su ja susijusiomis problemomis. Patikrinkite, ar nėra tuštumos masyvo su mėginių rezultatais. Pavyzdžiui, paskutinį kartą su šia problema susidūriau dirbdamas su viena internetine parduotuve. Skundas: puslapiai kartais įkeliami per 16 sekundžių. Su kuo tai susiję – neaišku. Bandymu ir klaidomis išsiaiškinau, kad puslapiai nepadoriai ilgai kraunasi tik tada, kai krepšelis tuščias. Atrodė, kodėl? Kaip paaiškėjo, užvedus pelės žymeklį virš krepšelio pasirodė iššokantis langas, kuriame buvo rodomi į krepšelį įdėtos prekės vaizdai. Taigi, ką padarė ankstesnis kūrėjas? Paėmiau komponento „mažas krepšelis“ darbo rezultatą ir faile result_modifier.php pakviečiau prekių GetList () iš produktų ID masyvo atrinkti vaizdus su filtru, tada iš atrankos rezultatų. prie atitinkamo produkto masyvo pridėtas vaizdo src. Dėl to, kai krepšelyje nebuvo prekių, filtras ištuštėjo, o į pasirinkimą pateko VISAS prekių katalogas. Na, tada ciklas kiekvienam ir ... turime tai, ką turime. Akivaizdu, kad kūrimo etape su 15 bandomųjų gaminių tai buvo nepastebėta, o problemų iškilo jau kovinėmis sąlygomis. Nors atrodytų, kad buvo verta uždėti čekį ant tuščio ($arResult["ITEMS"])...
Tai užbaigia mano asmeninę „blogiausią praktiką“, susijusią su „Bitrix“ kūrimu. Jei bent kažkam ši informacija padeda išvengti klaidų ateityje ir pagerinti savo tobulėjimo stilių, vadinasi, tai buvo ne veltui.
Kaip išjungti skelbimus „Android“: pašalinkite iššokančiuosius skelbimus
Rusas gavo terminą ir milijoninę baudą už „piratavimą Neigiamos įstatymo pasekmės
Pagrindinių veiksnių nustatymas
Pasikeitė organizacijų ir individualių verslininkų priskyrimo prie smulkaus ir vidutinio verslo kriterijai
Pažiūrėkite, kas yra „autorinis atlyginimas“ kituose žodynuose. Teisės aktų spąstai