WooCommerce CSS有助于更改订单注释框的大小
我正在尝试更改wooCommerce admin编辑订单中的“添加”注释框的高度大小
- :
我不得不调整此盒子大小,我希望高度约为200 px而不是50。
元素是 textarea#add_order_note.input -text
.add_note #add_order_note {
width: 100%;
height: 50px;
}
我希望有人可以建议我需要通过外观输入的正确CSS代码 - 自定义 - 其他CSS,或者我应该使用代码片段?
我已经尝试了一些不同的CSS尝试,但是我不知道如何正确输入代码
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我找到了一个解决方案。
将其添加到您的功能主题中。
I found a solution.
Add this to your functions theme.
将以下代码段添加到您的活动主题
functions.php
使用 woocommerce 6.3 测试的正常。可以使用WP标准函数
admin_enqueue_scripts
是当应在管理面板中使用。尽管有名字,但它用于启动脚本和样式。Add the below code snippet to your active theme
functions.php
Tested OK with WooCommerce 6.3. Adding the style override to an existing style sheet can be done using the WP standard function wp_add_inline_style()
admin_enqueue_scripts
is the proper hook to use when enqueuing scripts and styles that are meant to be used in the administration panel. Despite the name, it is used for enqueuing both scripts and styles.在CSS中:
In css:
看到这是一个更改,您想通过插件更新,主题更新等持续存在。应该在您的孩子主题的CSS文件中进行。如果您不确定我的意思,我强烈建议您在继续开发之前使用子主题阅读。有 woocommerce 的教程好吧,除了在wordpress.org上找到的。
另一种选择是为CSS更改设计的插件,即JetPack,如实践文档。
尽管有很多方法可以实现这一目标,但从设计和可维护性的角度来看,将摘要添加到您的
function.php
并不理想。应该保留用于逻辑(功能性,业务逻辑,无论您选择的术语如何)而不是布局(视图,显示等)更改。 WordPress建立在MVC的原理上,最好尽可能维持代码的逻辑分离。即使在“外观 - 自定义 - 附加CSS”中,也比functions.php
更好 - 尽管我更喜欢完全避免使用它,因为它可能很快变得混乱且难以维护。Seeing as this is a change you want to persist through plugin updates, theme updates, etc. It should be made within the CSS file of your child theme. If you're unsure what I mean by that, I highly recommend you read up on using a child theme before any continued development. There is a tutorial from Woocommerce about this as well, besides those found on Wordpress.org.
Another alternative is a plugin designed for CSS alteration, i.e. Jetpack, as mentioned in the Woocommerce Best Practices Documentation.
While there are many ways to accomplish this, adding a snippet into your
functions.php
isn't ideal from a design and maintainability perspective. That should be reserved for logical (functional, business logic, whatever term you choose) changes, rather than layout (view, display, etc) changes. Wordpress is built on the principles of MVC and it's best to maintain that logical separation of code whenever possible. Even in "Appearance - Customize - Additional CSS" is better than infunctions.php
- although I prefer to avoid using that altogether, as it can quickly become cluttered and difficult to maintain.