/* Theme Name: CozyCorner Child Theme URI: https://demo.theme-sky.com/cozycorner/ Author: Theme Sky Team Author URI: http://theme-sky.com/ Description: A Premium and Responsive WordPress theme, designed for E-Commerce websites Template: cozycorner Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: two-columns, left-sidebar, custom-background, custom-colors, custom-header, custom-menu, editor-style, featured-images, microformats, post-formats, rtl-language-support, sticky-post, threaded-comments, translation-ready Text Domain: cozycorner-child */ /*== XLM-UNIFORM-PRODUCT-IMAGE-START ==*/ /*------------------------------------------------------------- 商品列表图统一为 1:1 正方形（2026-09-11） 父主题 framework/woo_hooks.php:227 把列表图的 width/height 硬编码成 wc_get_image_size() 返回的 600x600，但 WordPress 的 image_resize_dimensions() 拒绝放大 —— 原图宽度不足 600 时只会生成 370x600 / 413x600 / 338x600 这类文件。 属性与文件不符，而父主题 style.css:4707 的 width:100% 没有给高度，浏览器只能 按文件真实比例算高度（270px ~ 479px），同一行卡片因此高矮不一。 这里给图片一个固定的 1:1 视口。 2026-09-12 更新：object-fit 从 cover 改成 contain。 cover 的语义是「填满方格、多余部分裁掉」，而商品封面大多是竖长条 （370x900 这类），cover 会把门裁得只剩中间一段；更麻烦的是 woocommerce_thumbnail(600x600, crop=1) 这个文件本身，WordPress 不肯 把 370 宽放大到 600，就只从原图中间裁出 370x600 —— 门的上下各被切掉 150px。两层裁切叠起来，卡片上只能看到门的大约 41%。 CSS 变不回已经被裁掉的像素，所以同时做了两件事： (1) 本文件这里改成 contain —— 整张图完整放进方格，两侧留白； (2) functions.php 里挂钩子，把卡片图的尺寸换成「没有被裁切」的那个 （medium / large 等 crop=false 的尺寸），不再用 crop=1 的 woocommerce_thumbnail。 只改「怎么显示」和「取哪个尺寸的文件」，方格大小、网格布局、卡片尺寸 一律没动。4 张横图（2560x1927 的房间照）以前填满方格，现在会上下留白， 这是「完整显示整张图」的必然结果。 选择器带 .thumbnail-wrapper：商品分类组件里图标是 .product-category-wrapper > a > img，没有这层，因此不受影响。 -------------------------------------------------------------*/ .woocommerce .products .product .thumbnail-wrapper a img { aspect-ratio: 1 / 1; object-fit: contain; height: auto; } /*== XLM-UNIFORM-PRODUCT-IMAGE-END ==*/ /*== XLM-SINGLE-PRODUCT-IMAGE-HEIGHT-START ==*/ /*------------------------------------------------------------- 商品详情页主图限高（2026-09-11） 症状：详情页主图渲染到 1500px 以上（实测 XLM-10000 是 633x1540， XLM-7002 是 633x1781），右侧信息栏 400px 就结束了，下面一大片空白。 成因（三层，跟「图片优化」无关，是原图本身的性质）： 1) 主题对主图没有任何 max-height —— style.css 里 42 处 .woocommerce-product-gallery 规则、reset.css、responsive.css、 父主题 woo_hooks.php 全都没有限制高度；父主题 style.css 的 width:100% 让图铺满整列（633px），高度完全由原图比例决定。 2) 24 个商品里 20 个的封面是竖长条，比例 1:2.43 ~ 1:2.92 （370x900 / 413x900 / 593x1535 / 786x2211 等）。 3) woocommerce_single 这个中间尺寸根本没生成：父主题 theme_functions.php 把 woocommerce_single_image_width 设成 900， 而 WooCommerce 注册该尺寸时 height=0；WordPress 拒绝放大，宽度不足 900 的原图直接跳过这个尺寸，主图 src 回退到原图全尺寸。 修法：只给显示层加高度上限，宽度按原比例自适应并居中。 刻意不用 object-fit、不用 aspect-ratio 定框、不裁切 —— 因为 ts_prod_cloudzoom=1，主题启用了 WooCommerce 放大镜，它按鼠标在 「图片盒子」内的相对位置算 .zoomImg 偏移。这里 width/height 都是 auto， 盒子必然等于图片实际画面，zoom 的数学不会错位；一旦改成固定比例框 + object-fit，盒子和画面分离，放大镜就会显示错位的区域。 同理不动原图文件，符合「不要给图片加白边改构图」的既定约束。 选择器写成 .single-product.woocommerce（中间没有空格）：single-product 和 woocommerce 两个 class 是挂在同一个 上的，若写成后代选择器 .single-product .woocommerce 则要求后者是前者的后代，同一元素不满足， 整条规则会一条都不匹配（这个坑已经踩过一次）。 max-width 也一并声明，是为了让竖图走「宽高都 auto + 双 max 约束」这条 路径：浏览器会取宽高两个缩放系数里较小的那个，保持原比例，不会压扁。 （实测 2560x1927 的横图仍渲染 633x476，与改动前一致，不受影响。） -------------------------------------------------------------*/ .single-product.woocommerce div.product div.images .woocommerce-product-gallery__wrapper img { width: auto; height: auto; max-width: 100%; max-height: 600px; display: block; margin-left: auto; margin-right: auto; } /*== XLM-SINGLE-PRODUCT-IMAGE-HEIGHT-END ==*/ /*== XLM-FOOTER-HEADING-SIZE-START ==*/ /*------------------------------------------------------------- 页脚地址标题在小屏过大（2026-09-12） 成因：父主题 css/reset.css 里有一条超长选择器组，第一个选择器就是裸 h3： h3, #customer_login h2, ... { font-size: var(--ts-h3-font-size); line-height: var(--ts-h3-line-height); } h3 单独算特异性只有 0,0,1，字号完全由变量 --ts-h3-font-size 决定 （uploads/cozycornerchild.css 里定义：>=1201px 是 35px/40px，<=1200px 是 25px/30px， 991 和 767 两档不再下降）。页脚正文（电话/邮箱/链接）只有 14px， 所以手机上地址是它的 1.8 倍，25px 要排 6 行 / 180px 高。 首页用的页脚块(11166) 和其它所有页面用的页脚块(11858) 实测表现完全一致。 另一条线索（本次未采用，别重复试）：这两个页脚块里的 atomic 标题部件在 Elementor 里 似乎有局部排版设置，但全站 15 个样式表里都没有生成对应的 .e-xxxxxxxx-xxxxxx 规则， 那些设置实际是被丢掉的 —— 改 Elementor 里的排版不会生效。 修法：在页脚范围内把这个变量降到主题自己的下一档，不写死像素、跟着主题阶梯走。 --ts-h4-font-size 自己会在 1200px 处从 30px 变成 20px。 只在 <=1200px 生效（和主题切换这套阶梯的断点一致），>=1201px 完全不动。 实测（首页 / about / product 三页结果一致，地址标题字号）： 1440 / 1280px : 35px 不动 1200 ~ 1024px : 25 -> 20px 右栏链接列 106->129 / 70->92 992 ~ 768px : 25 -> 20px 右栏链接列 63->85 / 17->39 <= 767px : 25 -> 18px 390px 时地址从 6行180px 变成 4行88px 逐元素回归核验：页脚里除地址标题外没有任何元素的字号发生变化，无横向溢出。 已知遗留（都写在这里，别重复排查）： 1) 768~1024px 右栏仍偏窄（768px 时每个链接列 82px，链接折成 2~4 行）。 根因同上：左栏宽度 = 地址标题最大内容宽 + 100px 内边距，且 flex-shrink:0。 一行能解，但会把地址从 2 行压成 4~5 行（1024px 时 60px 高 -> 96px 高）， 与「让地址变小」的初衷相反，故本次不采用： @media (max-width:1024px){ footer#colophon .e-con:has(> .e-heading-base){ flex-shrink:1; } } 若将来采用它，必须同时加上下面这条，否则邮箱会被裁掉 （实测 1024px 时 292px 宽的内容挤进 228px）： footer#colophon .elementor-icon-list-text{ overflow-wrap: anywhere; } 2) <=390px 时邮箱 zhouyanchao20010525@outlook.com 被裁（272px 挤进 240px）。 这是改动前就存在的，与本次无关；上面那条 overflow-wrap 也能一并解决。 -------------------------------------------------------------*/ @media (max-width: 1200px){ footer#colophon{ --ts-h3-font-size: var(--ts-h4-font-size); --ts-h3-line-height: var(--ts-h4-line-height); } } @media (max-width: 767px){ footer#colophon{ --ts-h3-font-size: var(--ts-h5-font-size); --ts-h3-line-height: var(--ts-h5-line-height); } } /*== XLM-FOOTER-HEADING-SIZE-END ==*/ /*== XLM-FOOTER-LINK-COLUMN-START ==*/ /*------------------------------------------------------------- 页脚右侧链接列被压成折行 / 上下堆叠（2026-09-12） 成因：右栏 .e-con 里两个 icon-list 部件的宽度是「父容器的百分比」 （实测恒为 20.6%），跟部件自己的文字内容无关 —— 右栏再宽，这两个 部件也不会自己变宽。右栏只有宽到约 900px 以上，20.6% 才够放下最长 的「Returns & Exchanges」（含图标约 183px）；窄于此就折行，两个部件 还会被挤成上下堆叠。 修法：给右栏的链接部件一个 max-content 下限，让宽度跟着文字走、 不跟百分比走。用 ~ 只圈右栏 —— 地址栏自己的 .e-con 里也有同一个类 （电话/邮箱那两条白色胶囊），那是要撑满整栏的，不能动。 为什么是 768px：逐档实测（320 -> 1920）发现这条规则在**任何**宽度都 不溢出、不折行、不堆叠，本可以不带媒体查询；但手机端（<768px）加了 之后链接列从 104px 变 137px，文字右伸到 x313，正好钻进右下角 WhatsApp 悬浮按钮底下（实测重叠 12x22px）。所以只开到 768px：补上 768~899 这段 本来折行+堆叠的区间，手机端保持原样。 实测（逐档 320->1920，同时验折行/堆叠/横向溢出/部件超出右栏）： <768px 与改前完全一致（列宽、行数、堆叠、页脚高全同等） 768px [58.1,58.1] 3行 叠 页脚842 -> [85,167] 1行 并 页脚774 800px [64.7,64.7] 2行 叠 页脚820 -> [85,167] 1行 并 页脚774 860px [77.1,77.1] 2行 叠 页脚820 -> [85,167] 1行 并 页脚774 899px [85.1,85.1] 2行 叠 页脚820 -> [85.1,167] 1行 并 页脚774 900px 以上本轮不变（旧的 900px 版本已经修好） 地址字号 / 行数 / 左栏宽度在任何宽度都没动过。 历史：本块最早写成 @media (min-width: 900px)，是照着当时「左栏被地址 标题锁死在 865px、右栏只剩 296~535px」的老布局定的阈值。后来地址栏在 Elementor 里被改窄（左栏 865 -> 615px），右栏变宽，阈值就可以降下来。 -------------------------------------------------------------*/ @media (min-width: 768px){ footer#colophon .e-con:has(> .e-heading-base) ~ .e-con .elementor-widget-icon-list{ min-width: max-content; } } /*== XLM-FOOTER-LINK-COLUMN-END ==*/ /*== XLM-FOOTER-WHATSAPP-CLEARANCE-START ==*/ /*------------------------------------------------------------- 页脚底部留白：让右下角 WhatsApp 悬浮按钮不压住链接（2026-09-12） 按钮自身 CSS（在页脚的 Elementor HTML 部件里，非本文件）： .wjp-wa{ position:fixed; right:30px; bottom:98px; z-index:9999 } 58x58 @media (max-width:480px){ .wjp-wa{ right:16px; bottom:78px } } 它固定占住视口底部往上 98~156px 那一条，与滚动位置无关。 实测各宽度「页脚文字底边超出按钮顶边」多少（= 需补的 padding，1:1 抵消）： 320~360px 66px 压「Shipping Info」 375~767px 0 768~935px 55px 压「Shipping Info」/「Returns & Exchanges」 940px 以上 0 取最狠的 66px + 24px 余量 = 90px。 为什么用 max-width:1200px 而不是精确区间： 压字位置随文字换行非单调变化（320/340 压、360/375 不压、376/380 又压）， 精确区间既难写又会被任何一次页脚文案改动打翻。1200px 正好与本文件里 页脚地址字号降级的那一档（@media (max-width:1200px)）对齐，行为一致。 :has(.wjp-wa) 是自解释兼保险：哪天把悬浮按钮撤了，留白自动消失。 实测（320->1920 共 34 档，含 911/915/920/930/935/1200/1201 边界）： 全部宽度均无任何页脚文字被按钮压住； <=1200px 页脚高度 +90px（多为纯黑留白）；>=1201px 完全不变。 -------------------------------------------------------------*/ @media (max-width: 1200px){ footer#colophon:has(.wjp-wa){ padding-bottom: 90px; } } /*== XLM-FOOTER-WHATSAPP-CLEARANCE-END ==*/