| 开发者 | fyrins |
|---|---|
| 更新时间 | 2026年11月2日 18:30 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPL-2.0-or-later |
| 版权网址: | 版权信息 |
position: fixed stops being fixed to the viewport, and z-index inside the block is measured against the block instead of the page.rotatile_supported_blocks sets the block types, rotatile_min_angle and rotatile_max_angle set the range, rotatile_step sets the increment, rotatile_default_angle sets the starting value, and rotatile_transition_duration sets or removes the transition. The development README documents each one with an example.
Source code and build
The editor script shipped in build/ is compiled from src/editor.js. The uncompiled source, the build configuration and the full history live in the public repository:
https://github.com/Fyrins/rotatile
The toolchain is @wordpress/scripts, the build tool maintained by the WordPress project, and nothing else. To reproduce the shipped file:
git clone https://github.com/Fyrins/rotatile.git cd rotatile npm install npm run build
The front-end stylesheet is not compiled: assets/css/rotatile.css is written by hand and shipped as it reads.
wp-content/plugins and activate it.Because rotating text is a readability problem rather than a design feature. Anyone who genuinely needs another block type can say so in code, and that decision then lives in their theme instead of being the plugin's default.
Add this to your theme's functions.php or to a small plugin of your own:
add_filter( 'rotatile_supported_blocks', function ( $blocks ) { $blocks[] = 'core/group'; return $blocks; } );
No. The angle lives in the block comment, which block validation ignores. The markup stored in your database is exactly what the block's own save function wrote.
They stop being rotated, and that is all. No block is invalidated, no content is lost, and there is no cleanup to do.
No, that is how CSS transforms work. The layout box stays where it was and only the paint is rotated, so the corners of a tilted element reach outside their box. Add spacing around the block, or use a smaller angle.
Check whether the rotated block is set to full-width alignment. A block that already spans the viewport has nowhere to put its rotated corners, so they end up past the edge of the page and the browser offers a horizontal scrollbar. A block inside the normal content width does not do this, even at 45 degrees. Either drop the full-width alignment or use a smaller angle.
A transform turns the element into a containing block, so position: fixed inside it becomes relative to the block rather than to the viewport. That is a browser rule and the plugin cannot opt out of it. Rotate the inner element instead of the container, or drop the fixed positioning.
Yes, and it is already off for anyone who has asked their operating system for reduced motion. To remove it for everybody:
add_filter( 'rotatile_transition_duration', '__return_empty_string' );
No. There is no telemetry, no external asset and no outgoing request of any kind, and no option is written to your database.
It is being worked on in the Gutenberg project, and it is not part of WordPress 7.2. If it ships in a later release, it will store its angle somewhere else and use the CSS rotate property rather than transform, so the two do not break each other. They do add up, though: set the angle in one place only. Once the core setting is available on your site, it is the better choice for new content.
render_block and the HTML Tag Processor, with nothing written to the saved markup.prefers-reduced-motion.