treba ze se nebudu vrtat v software kterej jsem sam neudelal a nikto me za to neplati?
v vlastnem sw fixnu co chci, jak chci - tady bych musel prohledavat komplet zdrojak neceho co se mi zmeni pod rukama kompletne treba v pristi verzi...
nejlepsi je delat bez frameworks))) (max udelat vlastni funkce + pridat jquery a mozna nejake php libraries treba pro spracovani excel)
No a proč máš vůbec framework, na kterém ti evidentně nezáleží ani tolik, abys opravil kritickou zranitelnost? Mimochodem kritická chyba v supr čupr cool "php libraries" nebo jQuery na kterých máš postavený kód se liší jak od chyby ve frameworku na kterém máš postavený kód?
Tak problem muze byt i v tom, ze aktualizace muze rozbit custom speciality delane na miru a ne uplne korektne. Problem muze byt v tom ze provozovateli daneho www reseni to muze byt jedno, nebot se to na provozu neprojevi, nebo provozovatel projevy nevidi/nepocituje a tak to neresi.
V pripade custom uprav je to na odbornejsi zasah blize urovne tvurce frameworku a tady uz jsme spise blize tomu, ze vlastnimu kodu clovek mnohem lepe rozumi nez cizimu kodu ruzne kvality. Kuprikladu ja se nedavno podival na Magento. No vetsi kombinaci vseho mozneho se vsim moznym a navic tak nehorazne na systemove prostredky narocnou a noptimalizovanou (dziliony zbytnych SQL dotazu per request zminuju jako jednu vec ze ktere mi padla huba na zem) jsem jeste nevidel a to tenhle framework je vetsinou opevovany jako neco senza uzasneho pouzivaneho korporaty. Ja bych rek, ze proste do takoveho korporatu prijali lepice co dokaze hotove kusy slepit a vypada pred neodborniky jako obrovsky profik, a ne programatora, co dokaze kreativne a efektivne vyvijet a profikem skutecne je, coz ale neodbornik neoceni, nebo pochopi az hodne pozde, kde je ten propastny rozdil.
Pritom na funkcne stejne reseni castokrat staci napsat projekt from the scratch, s pouzitim opakovanych a overenych veci z jinych nasich projektu stejneho "kalibru" (treba login/logout/sessions, kosik, pokladna...) s vyuzitim jquery a mame vse co k zakaznikovu stesti potrebujeme. Pokud jsme dobry programator a vime co delame, ficury od jinych nepotrebujeme bo jsme schopni si je napsat par radky taky a vime-li skutecne co delame, tak i tak, aby kod byl bezpecny, popripade jsme schopni zajistit opravu mnohem drive nez se vyvojovy tym frameworku o chybe vubec dozvi a necha si vyargumentovat, ze to je chyba na jejich strane a ze to maji opravit.
Tohle jsou vymluvy a pomluvy smerem kam nevidite. Zrovna tahle chyba nedela zadne custom speciality delane na miru ani je nerozbiji, je to proste jen oprava vstupu proti nejake forme injection.
Oprava teto chyby byla reportovana tyden pred zverejnenim chyby vcetne relativne presneho casu kdy oprava vyjde. Opravu bylo mozno naprosto jednoduse aplikovat jako patch. Kazdy slusny clovek, ktery dela Drupal za penize to zakaznikum aplikoval (mimochodem vysla i oprava pro Drupal 6, ktery je jiz par let EOL).
Jen uživatelé dlabou na aktualizace. Stejně jako by kašlali na případnou opravu vlastního řešení.
Trochu chybou vývojářů je, že zákazníky neinformují o pro a proti používání komponent třetích stran. Vývojáři to berou tak, že jim to ušetří práci a zákazníkovi peníze. Zákazník samozřejmě slyší na cenu. Vývojář už zase pak neřeší údržbu předaného projektu. Proč by to řešil? Kdyby to řešil dopředu, bude zákazníka děsit budoucími náklady. Proto se o nutnosti údržby mlčí a projekty vypadají, jak vypadají.
Protože jim pořád vychytralí marketingoví "specialisti" vypečených výrobců vtloukají do hlav že se díla nedají udržovat a záplatovat, o jasných budoucích problémech se jaksi náhodou zapomenou zmínit a tak s tím lidi tak nějak ani nepočítají. Pak je tu hromada vývojářů pro které je nějaká údržba nebo aktualizace teprve další level kam by se chtěli jednou posunout a tak zatím jenom dělají kšefty na Webtrhu za polovic a pak to po nich chtěj, aby informovali klienta ...
A ty jsi teba v mailing listu výrobce tvého auta, kotle, ledničky, televize, routeru, mobilu, ..... ? Kolik už vyšlo záplat na tvé auto?
Na D8 uz ani upgrade neni mozny. Misto toho je Migrate. Jadro nema s BC problem, ale zkus premluvit lidi, kteri ve volnem case delaji contrib? Ty zasadni a dulezite moduly vsak presto nejakou upgrade path vetsinou drzi.
Jo a mimochodem https://drupal.org/project/D6LTS