Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Css Javascript Browser

Eliminar CSS no utilitzat trenca el menú mòbil: com reparar-ho

Repara un menú mòbil de WordPress trencat en eliminar CSS no utilitzat, localitza selectors dinàmics i limita les exclusions.

La versió d’escriptori continua veient-se bé després d’optimitzar el CSS, però al mòbil el menú s’obre sense posició, roman invisible o cobreix la pàgina de manera incorrecta. És probable que l’eina analitzés només l’estat inicial tancat i eliminés selectors que s’utilitzen quan JavaScript afegeix una classe.

Primer cal recuperar una navegació fiable i després reduir l’excepció. No té sentit obtenir un full d’estils més petit si una part dels visitants ja no pot recórrer el web.

Confirmar que l’eliminació de CSS causa l’error

En staging, o mitjançant el paràmetre segur d’omissió de l’eina, desactiva únicament la funció de CSS no utilitzat. Mantén sense canvis la memòria cau i els ajustos de JavaScript. Repeteix la prova com a visitant desconnectat i amb la mateixa amplada de pantalla.

Si el menú torna a funcionar, compara el CSS original amb l’optimitzat. Si continua trencat, investiga JavaScript retardat, una actualització del tema o recursos generats que hagin quedat obsolets.

Anota si el botó adopta l’estat obert i si l’element del menú canvia de classe o atribut ARIA. Aquesta diferència separa un problema visual d’un de funcional.

Capturar els selectors dinàmics

Obre el menú i inspecciona què canvia al DOM. Un tema pot afegir estats com aquests:

<body class="menu-open">
  <nav class="site-menu is-active" aria-hidden="false">

Els estils necessaris podrien ser:

.menu-open {
  overflow: hidden;
}

.site-menu.is-active {
  opacity: 1;
  visibility: visible;
  transform: translateX(0);
}

Un rastrejador automàtic que mai prem el botó no veu aquests estats. També pot ometre submenús niats, estils de focus i el control de tancament.

Revisar les media queries

La regla necessària potser només existeix per sota d’un breakpoint. Compara el CSS exactament a l’amplada on apareix l’error i prova al voltant del límit: per exemple, 767, 768 i 769 píxels.

No incloguis a la llista segura només .is-active si el disseny també depèn de classes pare, pseudoelements o regles dins de @media. Conserva el grup complet més petit que permeti utilitzar la interacció correctament.

Comprova igualment l’orientació horitzontal i el zoom del navegador, perquè poden activar la navegació mòbil en una pantalla físicament ampla.

Conservar patrons estables

Utilitza l’exclusió o llista segura documentada per l’optimitzador per als selectors confirmats. És preferible conservar un prefix estable com .site-menu que una classe amb hash generada per un constructor i susceptible de canviar quan es regeneren els recursos.

No facis servir patrons generals com qualsevol classe que contingui active: podrien retenir bona part del full original. Tampoc no n’hi ha prou de recuperar una sola regla visible si encara falten els estats de focus o de submenú.

Documenta per què es conserva cada selector. Així una neteja futura no repetirà el mateix incident.

Separar el CSS del temps d’execució de JavaScript

L’eliminació de CSS i el retard de JavaScript sovint s’activen alhora. És possible que l’estil hi sigui, però que el controlador del clic encara no s’hagi executat.

Busca errors a la consola i observa si en prémer canvien aria-expanded o les classes del menú. Si només funciona després de fer scroll, el bloqueig probablement prové de JavaScript retardat, no pas de CSS absent.

Canvia una funció cada vegada. Excloure simultàniament l’script i el CSS impedeix saber quina reparació era necessària.

Regenerar i verificar en l’ordre correcte

Després d’ajustar la llista segura, regenera el CSS utilitzat, purga la pàgina afectada i després la memòria cau del CDN. Un constructor visual també pot necessitar regenerar els seus fitxers CSS. Evita esborrar directoris de memòria cau manualment en producció: usa els controls admesos i confirma que la URL nova retorna el fitxer correcte.

Prova en una sessió neta, sense la barra d’administració. Confirma que el menú s’obre i es tanca amb ratolí i teclat, mostra l’estat expandit correcte, conserva un focus visible, permet usar submenús, bloqueja el desplaçament de fons quan correspon i retorna el focus de manera lògica en tancar.

Revisa la capçalera a la portada, una entrada, la pàgina de servei i el checkout si comparteixen navegació. Si els noms de classe són variables, existeixen diverses plantilles de capçalera o el CSS canvia segons la memòria cau, cal una reparació tècnica que sobrevisqui a la regeneració següent, no una correcció que només es vegi bé en una captura.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència