[Solved] Making Changes Breaks Website

[jesse.rogers 1]

Environment:
WordPress 4.7.3
DMS 2.2.1.1

I'm trying to add an interactive list of jobs on a page on our site. I keep trying to add a new Canvas Area and a PL Next Box inside of it, containing some HTML. When I hit publish and refresh, it seems to strip out all CSS from both the webpage and the DMS interface editor itself. Since most of the DMS editor isn't accessible in this state, I have to revert the site back from a backup once this happens, and lose all my changes. 

It looks like this:

In an incognito window, it's displaying the whole site and the PL Nextbox HTML properly, but no changes that I make to the stylesheet are reflecting. Strangely, javascript changes seem to come through just fine.

You can see the page here: http://adaptiva.staging.wpengine.com/careers/

I spoken to my hosting provider, and they said that caching is disabled on their staging servers, so it shouldn't be a host cache issue.

This is an extremely urgent matter for me, as we cannot update our stylesheet in this state. Any help is greatly appreciated.

[jesse.rogers 1]

By the way, I tried updating to the latest version of DMS 2, but it gives me the "Oops, There may be an issue loading" error, even when I disable all plugins. I'm really not sure what to do. DMS has become completely unusable for me in the last week.

[jesse.rogers 1]

Update: I enabled "alternate CSS URLs" and it seemed to fix the problem temporarily. However, after a few refreshes, the DMS interface fell apart again.

I'm starting to suspect improper LESS compilation as one of the issues that keeps stripping CSS from my site when I'm logged in, barring me from using the DMS editor interface. If I view my LESS file straight from the server in browser, I can see all recent changes. However, the compiled CSS sheet it generates is not reflecting the same changes.

But, I've never had any issues with our LESS file and its compiler until this, so I don't know. I'm not even sure if we're using npm to compile our LESS sheet, or if DMS has a compiler built in, or what.

[jesse.rogers 1]

I am now almost certain that something is wrong with how DMS is compiling LESS files. I've thoroughly linted the compiled file and found many compiling errors, most of which came from the original theme's LESS files (/wp-content/themes/dms/less/).

There's only one instance of a compiling error from our custom LESS sheet, which should be compiling wrong at all.

Original code:

.video-right-text {
    display: block;
    position: absolute;
    top: 54px;
    bottom: auto;
    left: auto;
    right: 0;
    width: 34%;
    padding: 0 2em;
    z-index: 2;
    box-sizing: border-box;

    h2 {
        margin-top: 0;
        @media @mobile {
            margin-top: 1.618em !important;
        }
    }

    p {
        color: @black;
    }
    @media @tablet {
        position: static;
        top: auto;
        right: auto;
        width: 100%;
    }
    @media @mobile {
        position: static;
        top: auto;
        right: auto;
        width: 100%;
        padding: 0 1em;
    }
}

Though there are no errors in the nested h2 section, it compiles that part to:

.video-right-text h2 margin-top:0 @media @mobile {
    margin-top: 1.618em !important
}

There are many other LESS variables being carried over through compilation as well. I'm almost certain that this is what is breaking my site, which means that our production site is sitting on something very unstable right now.

I'd really appreciate someone getting back to me ASAP, as I posted this two days ago?

[Andrew 207]

ya DMS has a  PHP compiler built in that can cause some issues, have you opened up your database and found where it is storing the cached CSS? 

Do you have a lot of Custom CSS in there? Any errors in your server logs or anything?

[jesse.rogers 1]

No, I haven't looked through our database — is that something I would find in phpMyAdmin or something? I'm not particularly back-end oriented.

Yes, we have a pretty extensive custom stylesheet, around 4,000 lines. I've linted it relentlessly, and I've found no errors.

I can get my host's tech support to help me navigate the databases though. Can you let me know what to have them look for? Do you think clearing the CSS cache will fix the issue?

[Andrew 207]

I see, well, if you can get into PHPMyAdmin its not very difficult. Just navigate to your wp options table and do a search for DMS. 

I have another suggestion for you however, 

With PL5 we have a Custom LESS plugin that uses a MUCH more efficient way of handling LESS as it doesn't use your server to compile it... In DMS we used a PHP plugin to handle less compiling but it was early in the CSS preprocessor days and the script is buggy in several ways.

Does your site work fine without any custom LESS?

If so, then maybe you can try downloading PL5 and adding your custom stuff to the LESS plugin and fixing it that way. 

[jesse.rogers 1]

I do have PL5 running in the background on our site. I'll try cutting and pasting our LESS file into the PL5 console before I deal with PHPMyAdmin.

[jesse.rogers 1]

Went through and debugged our entire stylesheet before adding it to PL5's LESS console. I eventually discovered that DMS didn't like mixins of any kind. Removed all mixins, then pasted into PL5, saved and refreshed. So far so good.

[Brian 0]

I think that we're in the same situation with our DMS-based site at http://www.ros.org. Everything used to work but recently when we made an edit, we got the result that all CSS was gone. Looking into what the browser is requesting, we're seeing a 404 for a file named something like `http://www.ros.org/wp-content/uploads/pagelines/compiled-css-1495654726.css`. It appears that each page edit causes an expectation that the LESS compiler will run and produce a new compiled-css-XXX.css file, where XXX is replaced with the current timestamp in seconds from the epoch. But instead, what happens is that the latest compiled-css-XXX.css file gets removed and no new one is created. We can then manually get the site working again by copying some old compiled-css-XXX.css content into a file named with the new timestamp (which we can read out from the browser's 404).

So it would seem that the LESS compiler isn't running, or is encountering an error while running, or isn't producing output for another reason. Any tips on investigating the problem? Where can we look for errors from the LESS compiler?

I understand that upgrading to PL5 might be a way to go here, and I'm not ruling that out, but I want to first get the DMS site working again, as it's done fine for us for the past few years.

[Brian 0]

Possibly related, I see these lines at the bottom of the `/?pldebug=1` page:

 

DMS Internal Warning
Less Subsystem
POSIX checks failed.

Also these lines are in the debug output:

PHP User
Posix functions are disabled on this host!

[Brian 0]

I've found a workaround, which is to disable the POSIX check in `less.legacy.php`:

$ diff less.legacy.php.orig less.legacy.php
446,447c446,447
< 		if( false == $this->check_posix() )
< 			return pl_less_save_last_error( 'POSIX checks failed.', false );
---
> 		/*if( false == $this->check_posix() )
> 			return pl_less_save_last_error( 'POSIX checks failed.', false );*/

With that change in place, I can edit the site via the DMS editor and a new compiled-css file gets generated and the site continues to be rendered properly.

Does this finding imply that there's a problem with my hosting provider's PHP installation?

[jesse.rogers 1]

Hey Brian,

I don't think it's your host. My understanding is that the PHP compiler built into DMS is problematic. My workaround was to install PL5 on top of DMS and use the built-in custom LESS interface, which has a more stable, JS-based compiler.

I think the root of my problem was the use of LESS mixins. Even after I started leveraging PL5's LESS compiler, I found that it was still calling out error messages around mixins. As soon as I took them out, everything started working perfectly again. I have a hunch that could've fixed my DMS LESS sheet, too.

[Brian 0]

@jesse.rogers thanks for the feedback. When you are having LESS compilation problems, where do you look for errors? Something that has frustrated our debugging on this problem is the apparent lack of any errors or warnings. The only thing we can observe is the failure to produce the necessary compiled-css file.

[jesse.rogers 1]

I used LESSTESTER a bit, but in the end, when I copied over my stylesheet into PL5, I copied it section by section until I saw the interface flag something. It was incredibly tedious.

I also write my LESS out in Atom, which has linting capabilities to let me know the exact line that has an error — that helps keep me from submitting styles that will break something, but it didn't flag any of the mixins that were breaking my stylesheet. 

[hackwebmaster 0]

Hi, 

I am having this same issue, but I am not sure that I follow everything that is or is not working to fix this issue. I have taken on managing our site after it was made a couple of years ago so I am not completely sure where all the files are that are customized that could be broken, or need to be copied and added to a new plug in. I think the changes that have been done on our site have been to the iblogpro theme we're running, but I could be misunderstanding how DMS works with iblogpro.  Any other explanations for my very new-to-this-self would be greatly appreciated!

Thanks!

[jesse.rogers 1]

24 minutes ago, hackwebmaster said:

Hi, 

I am having this same issue, but I am not sure that I follow everything that is or is not working to fix this issue. I have taken on managing our site after it was made a couple of years ago so I am not completely sure where all the files are that are customized that could be broken, or need to be copied and added to a new plug in. I think the changes that have been done on our site have been to the iblogpro theme we're running, but I could be misunderstanding how DMS works with iblogpro.  Any other explanations for my very new-to-this-self would be greatly appreciated!

Thanks!

The problems we both had were with how DMS 2 was compiling our LESS stylesheets. LESS is like CSS on steroids, but it gets converted into regular CSS before the browser reads it. DMS does this on its own through a PHP script that its creators said is a little shaky. The script seems to have stopped working for a decent amount of people now. I had found that the LESS Mixins in my stylesheet were no longer supported by the compiling script, so I audited my stylesheet to remove all the mixins.

Then, I installed Pagelines' new product, Platform 5, since it's a free upgrade for existing DMS customers and pasted my audited stylesheet into Platform 5's "Custom LESS/CSS" panel. Platform 5 is more reliable with the LESS compilation.

Not sure if any of that makes sense or applies to your specific problem, but if it is the same issue, you'll be able to figure it out with some Googling.

Your LESS stylesheet would probably be in your theme folder or child theme folder on your hosting server.