/* Must be first: @import is only legal before other rules. Keeps the ban action-dropdown tinting (and its documented path, static/admin/bans.css) working unchanged now that JAZZMIN_SETTINGS["custom_css"] points here. */ @import url("bans.css"); /* ========================================================================== dallelha admin — Arabic typography + bidi correctness Loaded on EVERY admin page (JAZZMIN_SETTINGS["custom_css"]), in both languages. Purely RTL layout geometry lives in admin/rtl/*.css, which templates/admin/base_site.html loads only when the active language is bidi. Load order inside Jazzmin's : adminlte.min.css → bootswatch → jazzmin/main.css → THIS FILE → extrastyle The RTL sheets come last, in extrastyle, and are full flipped copies of the vendor CSS — so anything here that competes with a vendor rule at equal specificity would LOSE in Arabic. That is why the typography rules below are deliberately over-specific (`html body`, not `body`). ========================================================================== */ /* -------------------------------------------------------------------------- 1. Self-hosted IBM Plex Sans Arabic JAZZMIN_SETTINGS["use_google_fonts_cdn"] is False because Jazzmin's CDN font (Source Sans Pro) has no Arabic glyphs at all. Self-hosting also keeps the dashboard working with no outbound network. 400/500/600/700 x {arabic, latin}. unicode-range copied verbatim from @fontsource/ibm-plex-sans-arabic 5.3.0, so the browser only downloads the subset a page actually uses. IBM Plex is SIL Open Font License 1.1 — see fonts/IBM-Plex-LICENSE.txt. -------------------------------------------------------------------------- */ @font-face { font-family: "IBM Plex Sans Arabic"; font-style: normal; font-display: swap; font-weight: 400; src: url("../fonts/ibm-plex-sans-arabic-arabic-400-normal.woff2") format("woff2"); unicode-range: U+0600-06FF, U+0750-077F, U+0870-088E, U+0890-0891, U+0897-08E1, U+08E3-08FF, U+200C-200E, U+2010-2011, U+204F, U+2E41, U+FB50-FDFF, U+FE70-FE74, U+FE76-FEFC; } @font-face { font-family: "IBM Plex Sans Arabic"; font-style: normal; font-display: swap; font-weight: 500; src: url("../fonts/ibm-plex-sans-arabic-arabic-500-normal.woff2") format("woff2"); unicode-range: U+0600-06FF, U+0750-077F, U+0870-088E, U+0890-0891, U+0897-08E1, U+08E3-08FF, U+200C-200E, U+2010-2011, U+204F, U+2E41, U+FB50-FDFF, U+FE70-FE74, U+FE76-FEFC; } @font-face { font-family: "IBM Plex Sans Arabic"; font-style: normal; font-display: swap; font-weight: 600; src: url("../fonts/ibm-plex-sans-arabic-arabic-600-normal.woff2") format("woff2"); unicode-range: U+0600-06FF, U+0750-077F, U+0870-088E, U+0890-0891, U+0897-08E1, U+08E3-08FF, U+200C-200E, U+2010-2011, U+204F, U+2E41, U+FB50-FDFF, U+FE70-FE74, U+FE76-FEFC; } @font-face { font-family: "IBM Plex Sans Arabic"; font-style: normal; font-display: swap; font-weight: 700; src: url("../fonts/ibm-plex-sans-arabic-arabic-700-normal.woff2") format("woff2"); unicode-range: U+0600-06FF, U+0750-077F, U+0870-088E, U+0890-0891, U+0897-08E1, U+08E3-08FF, U+200C-200E, U+2010-2011, U+204F, U+2E41, U+FB50-FDFF, U+FE70-FE74, U+FE76-FEFC; } @font-face { font-family: "IBM Plex Sans Arabic"; font-style: normal; font-display: swap; font-weight: 400; src: url("../fonts/ibm-plex-sans-arabic-latin-400-normal.woff2") format("woff2"); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: "IBM Plex Sans Arabic"; font-style: normal; font-display: swap; font-weight: 500; src: url("../fonts/ibm-plex-sans-arabic-latin-500-normal.woff2") format("woff2"); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: "IBM Plex Sans Arabic"; font-style: normal; font-display: swap; font-weight: 600; src: url("../fonts/ibm-plex-sans-arabic-latin-600-normal.woff2") format("woff2"); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: "IBM Plex Sans Arabic"; font-style: normal; font-display: swap; font-weight: 700; src: url("../fonts/ibm-plex-sans-arabic-latin-700-normal.woff2") format("woff2"); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } /* -------------------------------------------------------------------------- 2. Typography `html body` (0,0,2) rather than `body` (0,0,1) so the flipped adminlte copy loaded after us cannot take the font back. Bootstrap's reboot already does `button,input,optgroup,select,textarea{font-family:inherit}`, so form controls, buttons and tables follow from body alone. 1.7 leading: Arabic needs more than Latin's 1.5 — the script has taller ascenders, deeper descenders and stacked diacritics. -------------------------------------------------------------------------- */ html { --dallelha-font-sans: "IBM Plex Sans Arabic", "IBM Plex Sans", "Segoe UI", system-ui, -apple-system, "Helvetica Neue", Arial, sans-serif; } html body { font-family: var(--dallelha-font-sans); line-height: 1.7; } /* The chrome is dense; keep it at Latin leading so nav items don't grow. */ html .app-header, html .app-sidebar { line-height: 1.5; } /* Arabic has no uppercase. Small-caps/uppercase transforms on Arabic text are no-ops that only make the Latin half of a mixed label shout. */ [dir="rtl"] .nav-header, [dir="rtl"] th, [dir="rtl"] .btn { text-transform: none; letter-spacing: normal; } /* -------------------------------------------------------------------------- 3. Bidi isolation for Latin data inside an RTL page The single most-missed detail in an RTL dashboard. Unicode's bidi algorithm gives neutral characters (+ - . : / @ digits' surrounding punctuation) the direction of their *paragraph*, so in an RTL cell the phone number +9647701234567 renders as 9647701234567+ — the plus jumps to the far end. Same for UUIDs, emails, FCM tokens and lat/lng pairs. `direction: ltr` fixes the character order, `unicode-bidi: isolate` stops the run from disturbing the Arabic around it, `text-align: right` keeps the column visually flush with its RTL neighbours. Applies to changelist cells () AND Jazzmin form rows, which emit `.form-group.field-` plus an inner `div.field-`. -------------------------------------------------------------------------- */ [dir="rtl"] .field-phone_number, [dir="rtl"] .field-owner_phone, [dir="rtl"] .field-center_phone, [dir="rtl"] .field-contact_phone, [dir="rtl"] .field-whatsapp_number, [dir="rtl"] .field-support_whatsapp, [dir="rtl"] .field-support_email, [dir="rtl"] .field-public_id, [dir="rtl"] .field-fcm_token, [dir="rtl"] .field-app_version, [dir="rtl"] .field-latitude, [dir="rtl"] .field-longitude, [dir="rtl"] .field-price, [dir="rtl"] .field-username, [dir="rtl"] .field-email, [dir="rtl"] .field-search_text, [dir="rtl"] .field-name_normalized, /* Every ForeignKey/OneToOneField to User, project-wide (verified by grepping every `settings.AUTH_USER_MODEL` reference — none of these field names are reused for a non-User relation anywhere). Django's changelist renders an FK column as plain str(related_obj) in a with NO extra wrapper, and str(User) is always the bare phone number. Confirmed bug: Product's "أنشأه" (created_by) column showed "9647...+". Whichever admin exposes one of these next is covered without another CSS edit. */ [dir="rtl"] .field-created_by, [dir="rtl"] .field-advertiser, [dir="rtl"] .field-reporter, [dir="rtl"] .field-reported_user, [dir="rtl"] .field-reviewed_by, [dir="rtl"] .field-banned_by, [dir="rtl"] .field-lifted_by, [dir="rtl"] .field-sent_by, [dir="rtl"] .field-customer, [dir="rtl"] .field-user { direction: ltr; text-align: right; unicode-bidi: isolate; } /* Inputs whose content is Latin by definition. */ [dir="rtl"] input[type="email"], [dir="rtl"] input[type="url"], [dir="rtl"] input[type="tel"], [dir="rtl"] input[type="number"] { direction: ltr; text-align: right; } /* Read-only technical values rendered outside a field- wrapper. */ [dir="rtl"] code, [dir="rtl"] pre, [dir="rtl"] .readonly time { direction: ltr; unicode-bidi: isolate; text-align: right; } /* Jazzmin's OWN chrome renders {{ request.user }} — always a phone number, since User.__str__ returns str(self.phone_number) — directly, with none of the field- wrappers above. Confirmed bug: "+9647701234567" rendered as "9647701234567+" in the sidebar user panel (base.html's .user-panel .info a.d-block / span.d-block.opacity-75). Scoped to .user-panel .info specifically — the visually adjacent #jazzy-usermenu dropdown has NO phone number in it (its header is the translated word "Account"), so it must NOT get this rule or its Arabic label would flip. */ [dir="rtl"] .user-panel .info { direction: ltr; unicode-bidi: isolate; text-align: right; } /* Django's own breadcrumb trail (Jazzmin's AdminLTE markup: ) renders the CURRENT OBJECT'S __str__ as plain text, unwrapped by any field- class. Confirmed bug: a User's change-page breadcrumb showed "9647701234567+" (same mangling as the sidebar, above). Unlike every other rule in this section, this element's content is NOT always Latin — the very same breadcrumb, one click away on a Product's change page, holds an Arabic name. `direction: ltr` would be correct for a User and wrong for a Product, so this uses `unicode-bidi: plaintext` instead: the browser detects direction from each breadcrumb's OWN first strong character (exactly how a bare already behaves — it is why typing "rtlcheck" into the username field above auto-aligned left with no CSS at all), so Arabic object names stay right-aligned RTL and phone-numbered / Latin ones correctly go LTR, per page. */ [dir="rtl"] .breadcrumb-item.active { unicode-bidi: plaintext; } /* Same problem, same fix, on Django's OWN delete-confirmation pages. admin/delete_confirmation.html and admin/delete_selected_confirmation.html (stock, unmodified — the "Yes, I'm sure" / single-object and the Django-provided "delete_selected" bulk action, as opposed to this project's own soft/hard-delete actions) list every cascaded row via {{ deletable_object|unordered_list }}: one

per str(object), completely unwrapped. A User row in that list is a bare phone number; a Product or Ad row starts with Arabic bracket/section text. Both templates tag with a stable "delete-confirmation" class (in their bodyclass block), which this project's own hard_delete_selected_confirmation.html also inherits unchanged (it only overrides content/content_title) — so one selector covers all three confirmation pages without touching a single vendor template. */ [dir="rtl"] body.delete-confirmation ul, [dir="rtl"] body.delete-confirmation ol { unicode-bidi: plaintext; } /* -------------------------------------------------------------------------- 4. Login page logo sizing AdminLTE sets no width/height/max-width on `.login-logo img` at all — it assumes the site owner supplies an already-appropriately-sized asset. static/logo/official_logo.png is a 1024x1024 export (an app-icon-style square, unlike the old 1009x575 wide lockup it replaced), so left unconstrained it rendered at its full natural size and pushed the actual login form ~400px below the fold. Language-agnostic (both login.html and Jazzmin's own registration/base.html use the same markup), so this lives here rather than in admin/rtl/dallelha-rtl.css. -------------------------------------------------------------------------- */ .login-logo img { max-width: 220px; height: auto; }