Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Less is not compiled "on the fly" in development mode #307

Closed
christophherr opened this issue Jul 19, 2018 · 3 comments · Fixed by #310
Closed

Less is not compiled "on the fly" in development mode #307

christophherr opened this issue Jul 19, 2018 · 3 comments · Fixed by #310
Assignees
Labels
Milestone

Comments

@christophherr
Copy link
Member

Adding from the forum: https://community.getbeans.io/discussion/compiler-not-disabled-in-development-mode/

I put the theme in development mode under appearance > settings. However each time I make a change in the CSS it still requires me to flush the cache assets for the change to show on screen. I am currently using Beans 1.5.0.
https://community.getbeans.io/discussion/compiler-not-disabled-in-development-mode/#post-4687
As far as I could figure out, the issue comes from line 687 of the _Beans_Compiler class (\tm-beans\lib\api\compiler\class-beans-compiler.php):
if ( file_exists( $fragment ) )
If you are using the starter child theme as a base for your child theme, you probably have a line in your functions.php along the lines of
beans_compiler_add_fragment( 'uikit', get_stylesheet_directory_uri() . '/style.less', 'less' );
As far as I can tell, all these fragments are passed to the Beans Compiler when it is constructed, and if your child theme is set up as assumed, the fragment is stored with reference to its URL. When the compiler gets to the previously mentioned if statement, it'll be checking file_exists with a URL, while it seems to need a local path to work (if passed a URL it always returns false, therefore skipping the next lines, which would change the modification time, which in turn is needed when computing the new hash to see if the file has been changed).

@hellofromtonya
Copy link
Contributor

@christophherr is this a regression issue as introduced in 1.5.0? Or has it been there previously?

@christophherr
Copy link
Member Author

@hellofromtonya
It sounds like a regression from the two posts on the forum. I haven't tested.

@christophherr christophherr changed the title Compiler not disabled in development mode Less is not compiled "on the fly" in development mode Jul 19, 2018
@hellofromtonya
Copy link
Contributor

I'm not finding a difference between 1.4 and 1.5. When in development mode, we do run the Compiler to convert LESS into CSS.

We just don't concatenate ALL of the stylesheets and then minify them into one stylesheet.

HOWEVER, we do have an issue that predates 1.5, which is: The compiler does not re-compile when in development mode. Whoopsie.

Proposed solution is:

	public function run_compiler() {
		// Modify the WP Filesystem method.
		add_filter( 'filesystem_method', array( $this, 'modify_filesystem_method' ) );

		$this->set_fragments();
		$this->set_filename();

		if ( ! $this->cache_file_exist() || _beans_is_compiler_dev_mode() ) {

Then it will recompile on every single page load.

hellofromtonya pushed a commit to hellofromtonya/Beans that referenced this issue Jul 22, 2018
This commit fixes Getbeans#307 by:

1. Flushing the cache when in development mode to avoid creating too many files.
2. Recompiling when in development mode.
hellofromtonya pushed a commit to hellofromtonya/Beans that referenced this issue Jul 22, 2018
This commit fixes Getbeans#307 by recompiling when in development mode.
@hellofromtonya hellofromtonya self-assigned this Jul 22, 2018
@hellofromtonya hellofromtonya added this to the 1.5.1 milestone Jul 22, 2018
hellofromtonya pushed a commit that referenced this issue Jul 22, 2018
Fixed #307 to recompile when in development mode.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants