WP-less does not generate new stylesheet all of sudden about wp-less HOT 23 CLOSED

wtih wp debug mode I could trace the following issues (I don't understand the error with bbp-default-bbpress, that's a css file, not a .less file - anyway if I deactivate bbpress the problem persists)

Notice: Undefined index: bbp-default-bbpress in /home/ntds/public_html/dev/content/plugins/wp-less/lib/Plugin.class.php on line 150

Notice: Trying to get property of non-object in /home/ntds/public_html/dev/content/plugins/wp-less/lib/Plugin.class.php on line 150

Notice: Undefined property: stdClass::$parent in /home/ntds/public_html/dev/content/plugins/wp-less/lib/vendor/lessphp/lessc.inc.php on line 2056

Notice: Undefined property: stdClass::$type in /home/ntds/public_html/dev/content/plugins/wp-less/lib/vendor/lessphp/lessc.inc.php on line 184

Notice: Undefined property: stdClass::$tags in /home/ntds/public_html/dev/content/plugins/wp-less/lib/vendor/lessphp/lessc.inc.php on line 210

Warning: Invalid argument supplied for foreach() in /home/ntds/public_html/dev/content/plugins/wp-less/lib/vendor/lessphp/lessc.inc.php on line 434

from wp-less.

I noticed yet another strange behaviour. I edited my old less stylesheet with a simple rule ( body * { color: red } ) - but I've found that at some point wp-less was generating a stylesheet. However this stylesheet was based on the old less stylesheet I had uploaded (and which nowhere existed anymore in my uploaded theme!). The stylesheet was invalid though, because it consisted of a bunch of css rules without classes or id (just the content of several { } ). I deleted the generated css stylesheet and yet it kept generating that flawed css based on a old version of my less stylesheet - I don't know where it was getting that, perhaps from cache? Nevertheless, I proceeded to uninstall phisically all wp-less files from the plugin folder after deactivating the plugin. Then I proceeded to copy the files from the github repo but upon activation wordpress threw this error:

Warning: require(/home/ntds/public_html/dev/content/plugins/wp-less/lib/vendor/lessphp/lessc.inc.php): failed to open stream: No such file or directory in /home/ntds/public_html/dev/content/plugins/wp-less/lib/Compiler.class.php on line 2

Fatal error: require(): Failed opening required '/home/ntds/public_html/dev/content/plugins/wp-less/lib/vendor/lessphp/lessc.inc.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/ntds/public_html/dev/content/plugins/wp-less/lib/Compiler.class.php on line 2

I proceeded then to install the plugin using the one in the wp.org repo, this time was activated, yet it keeps generating a file which is nowhere in my theme and it's based to a previous file which does not longer exist - I wonder where it is getting that file from!

from wp-less.

Sorry, this happened to be a problem with my server, spent the whole morning on it...

anyway for some reason wp debug is still reporting an error

Notice: Undefined index: bbp-default-bbpress in /home/ntds/public_html/dev/content/plugins/wp-less/lib/Plugin.class.php on line 150

Notice: Trying to get property of non-object in /home/ntds/public_html/dev/content/plugins/wp-less/lib/Plugin.class.php on line 150

seems that wp-less tries to add bbp-default-bbpress stylesheet as well? but that's a css file not a less file

from wp-less.

all that sudden is generally not a problem of a third-party but rather an incidence of a change ;-)

I guess there is something happening with a registered stylesheet somewhere. Maybe the stylesheets are registered late after it tries to compile but then, it does not make sense.

If it's a standard CSS file, it does not have incidence, as the plugin only process files ending by .less.

from wp-less.

I'm having this same problem. I deployed a site and everything compiles fine. Then a few weeks later (with ZERO change), the CSS file is no longer compiled and starts returning a 404. No idea why it was deleted and why it's not being recompiled, but WP-LESS keeps referencing a CSS file in /wp-content/uploads/wp-less/... that is not in the filesystem.

What did you end up doing to fix the issue? My whole uploads/ tree is already set to 777 (I thought it might be a permission problem).

from wp-less.

And when I turn on WP_DEBUG, all I get is:

Notice: wp_register_script was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or init hooks. Please see Debugging in WordPress for more information. (This message was added in version 3.3.) in /home/user_dir/public_html/wp-includes/functions.php on line 2959

So I have no idea whether that has anything to do with WP-LESS or not. Incidentally, once I turned on WP_DEBUG, the CSS file generated fine.

Is there a better way to track this?

from wp-less.

I'm wondering if this issue has to do with symlinked directories. We started having this problem intermittently across multiple WordPress sites. The one thing they had in common was that they're deployed through Capistrano, which means directories like /uploads/ are symlinked into the public_html directory tree.

Unfortunately we had to stop using the plugin since we had multiple clients complaining about "broken" sites. If this issue is ever resolved, we'd love to use the plugin instead of using the Mac LESS app.

from wp-less.

I had the same problem @nrutman and fixed it with the same solution.

from wp-less.

WordPress behaves pretty strangely with symlinks. It's really annoying.
The best way is to symlink and always register stuff the way WordPress is expecting them (from the root of WordPress install directory).

Also, it depends in which hook you are registering your stylesheet. Could you tell me in which one you did that?

One of the latest release of the plugin introduced a chance to avoids deleted all too old compiled files due to server-side caching issues (the cron task was run in the background and the compilation of the missing file never happened because nobody hit a dynamic copy of a page including the file).

It seems to be a quite random problem, I can't reproduce with certitude so every clue would help to definitely solve this issue :-)

from wp-less.

I forgot to mention that I also use symlinks (in zindows)
Enabling/Disabling the debug mode solves the problem, maybe this is a decent solution to this problem...

from wp-less.

Enabling the debugging makes the plugin to always recompile LESS files.

So it's a kind of workaround to regenerate files which have been wasted by the garbage collector (removing old/unused files).

from wp-less.

In my case, I only enabled/disabled the debug mode once to solve the issue.

from wp-less.

update: UAM plugin htaccess file in the upload folder was causing the problem

from wp-less.

@younes0 oh, do you know why? Because of a caching directive?

from wp-less.

UAM creates weird rewrite rules for handling files permissions
I had the same issue with the other WP Less plugin (https://github.com/sanchothefat/wp-less)

from wp-less.

@younes0 What is UAM? And what did you do to resolve the issue? Did you modify .htaccess?

from wp-less.

@nrutman User Access Manager plugin. I deleted the \wp-content\upload\ .htaccess (don't need the UAM file access feature) which is generated when you reset permalinks settings.

from wp-less.

@younes0 Hmm. The original problem still exists for me. The project I had problems on is a pretty straightforward, small site. I was using neither UAM nor any caching plugins. I don't have the .htaccess file you're referencing...

from wp-less.

got that same issue, very annoying: obviously, the .css file was generated - as could be seen on the FTP - but the .html still referenced to an old version.
In my case, it seemed to be WP Super Cache, even though the Plugin was disabled. I eventually enabled the plugin and disabled the caching function in the plugin settings, and now it works.

-> try disabling all caching plugins in any methods imaginable...

from wp-less.

I have the same problem as @mompracem, and I cant seem to find a solution. What was the server problem you had, @mompracem, and how did you fix it? I have tried all other options without any luck :/

from wp-less.

Sorry for the delay…

I guess it is related with #20 – internally WP-LESS thinks the CSS file is compiled but in reality, it has been pruned by the garbage collector process.

It's definitely a bug and not a misuse on your side guys. I have only a few time to work on it (especially as I'm almost not using WordPress anymore) so feel free to contribute by either pushing code or by hinting the incriminated lines of codes.

from wp-less.

how to solve this issue:Catchable fatal error: Argument 1 passed to Ozpital\WPWeTransfer\Core\OWPWT_Option::register() must be an instance of Ozpital\WPWeTransfer\Core\String, string given, called in /home/imraumqv/public_html/orbitgraphics/wp-content/plugins/ozpital-wetransfer/app/Core/OWPWT_Option.php on line 56 and defined in /home/imraumqv/public_html/orbitgraphics/wp-content/plugins/ozpital-wetransfer/app/Core/OWPWT_Option.php on line 22

from wp-less.

Closed, due to age. If the problem persists, please reopen the issue.

from wp-less.