Am articolul ăsta în draft de foarte mult timp, cred că peste un an. Ce m-a determinat să-l public a fost însă lansarea WordPress 3.7, versiune ce aduce – printre altele – și update-uri automate. Am văzut că mulți se plâng de acest lucru dintr-un motiv extrem de stupid: au fost făcute modificări în core-ul WP. Prin urmare m-am hotărât să public acest articol și, în plus, să scriu și despre câteva best practices în dezvoltarea de teme și plugin-uri pentru acest CMS.

Voi aborda un pic problema update-ului automat, că este cap de afiș pe foarte multe blog-uri.

Auto Core Update funcționează doar la versiunile minore. Asta înseamna că de la 3.7.0, cât este acum, se va face update automat la 3.7.1, 3.7.2 șamd. Când apare 3.8 NU se face update. În versiunea curentă NU se face update automat la plugin-uri sau la teme ci strict la fișierele din CORE. În momentul de față, singurul motiv pentru care cineva nu ar vrea activat auto-updater este că a făcut modificări în fișierele din Core, lucru profund greșit, având în vedere că, de-a lungul timpului, nu am avut nevoie niciodată de așa ceva (și s-a întâmplat să lucrez la site-uri destul de complexe).

Dacă vrei totuși să dezactivezi update-ul automat, este suficient să adaugi în wp-config.php următoarea linie:

define('DB_COLLATE', ''); // linia asta există deja
define( 'AUTOMATIC_UPDATER_DISABLED', true );

Dacă, din varii motive, vrei să dezactivezi update-ul doar din temă, este suficient să adaugi în functions.php

add_filter( 'auto_upgrader_disabled', '__return_true' );

În acest articol îți voi explica pașii ce trebuiesc făcuți pentru a avea un set-up de WordPress accesibil local.

Tot ce urmează pleacă de la premisa că ești fie pe Windows, fie pe OSX, că instalezi aplicațiile cu setările implicite și, cel mai important, ai cunoștințe de bază de HTML, CSS, PHP si MySQL. Dacă folosești Linux presupun că deja știi ce trebuie să faci și poți sări peste acest articol.

Prima problemă

Cea mai mare problemă la cei ce își dezvoltă singuri tema este că fac asta direct în producție (adică direct pe site-ul live).

De multe ori se mai întâmplă să uiți o virgulă, să nu pui o ghilimea bine iar site-ul crapă. În alte cazuri se poate întâmpla să vrei să folosești o funcție dar să-i scrii numele greșit și să nu observi când ești autentificat.

Prin urmare, ai nevoie de un server accesibil doar pe local, astfel încât toate experimentele și/sau greșelile sunt văzute doar de tine. Citeste mai departe »

Am avut primul contact cu iOS7 încă de la început, de la primul beta disponibil. Pe la beta 3 am început să testez un site în Safari și am avut doar „bucurii”. Speram să fie problemele caracteristice unui beta. Nu a fost să fie și, odată cu lansarea versiunii finale, Safari de pe iOS7 a devenit o problemă reală. Un mic rezumat:

• UI Changes: toolbar tint, problems with new full-screen navigation, new home screen icon sizes; no <title> usage on iPhone; possible conflicts with new gestures.
• New devices: nothing new about them for web developers, same as iPhone 5.
• HTML5 markup: video tracks, , REMOVED support for input type=datetime
• HTML5 APIs: Page Visibility, AirPlay API, canvas enhancements, REMOVED support for Shared Workers, Web Speech Synthesis API, unprefixed Web Audio and Animation Timing, Mutation Observer and other minor additions. BIG PROBLEM with WebSQL using more than 5Mb.
• CSS: Regions, Sticky position, FlexBox, ClipPath, unprefixed Transitions and other enhancements
• Home Screen webapps: SEVERAL SEVERE PROBLEMS (for example, no alert support!)
• Native webapps: Web View Pagination, JavaScript runtime for native apps and video playing new abilities

De aici.

Bonus.

De câteva zile mă tot lupt cu un site cu tot felul de animații, parallax și alte căcaturi eyecandy și consumatoare de resurse. Dacă pe PC nu se simțea nici o problemă, pe iPad totul era extrem (dar EXTREM!) de lent. După ce am optimizat și răs-optimizat codul JS (requestAnimationFrame, caching la greu etc; că tot veni vorba, folosește requestAnimationFrame întotdeauna!) mi-am adus aminte de articolul ăsta. Am mai folosit translate la câteva proiecte înainte, dar mai mult ca fiță, nu din motive de performanță (nu se simțea nici o diferență între top și translate), prin urmare nu prea luasem în calcul varianta asta când lucram la optimizare…

Este incredibil ce diferență de performanță poate exista între cele două modalități de animație! Totul a devenit brusc, extrem de smooth, până și pe iPad 1.
Citeste mai departe »