Stop rewriting my code

[Silverwulf]

Is there an easy / simple way to make Dreamweaver stop rewriting my code?

I have an input, it looks like this:

<cfinput type="text" id="txtIID" name="txtIID" value="#txtIID#" class="form-control" disabled="#isDisabled#">

The file saves fine as is with that proper format, but when I close the file and open it back up again, Dreamweaver rewrites that input to look like this:

<cfinput type="text" id="txtIID" name="txtIID" value="#txtIID#" class="form-control" disabled>

This might not be an issue if I had just the one. I could probably rewrite it by hand each time. Unfortunately there are about 4 dozen inputs on the page.

I've already looked into Dreamweaver's Preferences/ Code rewriting and Linting options and those don't seem to have an affect upon this issue.

Is there somewhere else I should be looking to turn off this behavior?

[Jon Fritz]

I can confirm the same bug exists in DWCC 2017.1 under Windows 7.

It's the same as the javascript rewrite bug Adobe fixed a little while back. The page looks correct when saved, but when reopened, it appears to rewrite the code.

The correct code is actually still in the page at this point (you can check by opening in notepad), however any change to the page and subsequent save in DW finalizes the rewrite.

Go to Help > Submit Bug/Feature request to report it to the dev team.

This kind of rewriting is inexcusable. Even if Adobe wants CF developers to switch to Cold Fusion Builder. DW shouldn't arbitrarily rewrite code it doesn't understand/support.

[BenPleysier]

• For XHTML, <input type="text" disabled="disabled" /> is the valid markup.
• For HTML5, <input type="text" disabled /> is valid and used by W3C on their samples.
• In fact, both ways works on all major browsers.

Even in ColdFusion you will find that

<cfinput type="text" id="txtIID" name="txtIID" value="#txtIID#" class="form-control" disabled>

is the correct format

[pziecina]

Sorry Ben, but no code editor should re-write anything, flag it as incorrect maybe, re-write never.

[BenPleysier]

[Silverwulf]

pziecina  wrote

Sorry Ben, but no code editor should re-write anything, flag it as incorrect maybe, re-write never.

Especially not without a way to turn it off when necessary.

[BenPleysier]

Can you use a ternary operator to show or not show the disabled attribute?

[Silverwulf]

BenPleysier  wrote

Can you use a ternary operator to show or not show the disabled attribute?

It's a possibility, but I'm not sure how we'd make it work.

We're already using a switch statement as well as other variables above to determine the state of the disabled or enabled inputs.

[BenPleysier]

It's been more than 10 years since I coded in CF, but here goes

<cfinput type="text" id="txtIID" name="txtIID" value="#txtIID#" class="form-control" #((isDisabled) ? 'disabled' : ' ')#>

[Silverwulf]

BenPleysier  wrote

It's been more than 10 years since I coded in CF, but here goes

<cfinput type="text" id="txtIID" name="txtIID" value="#txtIID#" class="form-control" #((isDisabled) ? 'disabled' : ' ')#>

I stuck that in to see what it would do and this is the error messages that I'm getting ...

Message: "Invalid CFML construct found on line 628 at column 190."
Details: "ColdFusion was looking at the following text: #

I think it has issues with just sticking the coldfusion # directly into the input.

If it would allow the pound symbols, I could probably just get away with using #isDisabled# there.

[BenPleysier]

Well there you go. I have lost my CF touch.

I totally agree that this is a glitch in Dreamweaver that should be corrected. As a work-around you could perhaps replace # with &#35;

I am working with a future version of Dreamweaver and cannot test it in the current version. Curiously, I cannot replicate the problem. This could be because I am not running a CF server.

As a side note, the disabled attribute is read by the browser as just that. Anything that comes after the attribute, like disabled="false" or disabled="disabled" or disabled="true", will be ignored. In other words, the result will not change because of the value.

[Silverwulf]

BenPleysier  wrote

Well there you go. I have lost my CF touch.

I totally agree that this is a glitch in Dreamweaver that should be corrected. As a work-around you could perhaps replace # with &#35;

I am working with a future version of Dreamweaver and cannot test it in the current version. Curiously, I cannot replicate the problem. This could be because I am not running a CF server.

As a side note, the disabled attribute is read by the browser as just that. Anything that comes after the attribute, like disabled="false" or disabled="disabled" or disabled="true", will be ignored. In other words, the result will not change because of the value.

How do I get my hands on that version?! 

As for the disabled attribute not caring what the value is, that's true. But fortunately, if it's left blank (disabled="") it works. Or it least it would if the code wasn't being rewritten.

I guess for now, I'll just have to stop using cfinputs and convert them all to inputs. It's not ideal, but they aren't leaving me with many options.

[Jon Fritz]

I can confirm that the same re-write bug also exists in today's update, CC 2017.5 Build 9878.

[Preran]

Thank you, Jon. Let me check with the team and see if the bug is still being investigated.

Thanks,

Preran

[Silverwulf]

https://forums.adobe.com/people/Jon+Fritz+II  wrote

I can confirm that the same re-write bug also exists in today's update, CC 2017.5 Build 9878.

Yeah, after the update yesterday I was holding out slim hope, but no such luck.

[Preran · Accepted solution]

A quick update:

It looks like there was no bug logged for this issue previously with the team. The team has logged a bug after they were able to reproduce this issue, and they hope to fix it in a future update.

To ensure that the team is aware of bugs reported here, please log your request here providing all details Adobe Dreamweaver CC: Feature Ideas

My team and the product team do our best to log bugs that you report on the forums, but we miss some in the process. Posting it using the link above will help us better track bug requests.

Thanks,

PReran

[Silverwulf]

Preran  wrote

A quick update:

It looks like there was no bug logged for this issue previously with the team. The team has logged a bug after they were able to reproduce this issue, and they hope to fix it in a future update.

To ensure that the team is aware of bugs reported here, please log your request here providing all details Adobe Dreamweaver CC: Feature Ideas

My team and the product team do our best to log bugs that you report on the forums, but we miss some in the process. Posting it using the link above will help us better track bug requests.

Thanks,

PReran

Thank you. I'm glad to hear that this issue will be looked into.

[Preran]

I have marked my answer as correct because this is the best possible answer for now. I will revisit this post when the bug is fixed.

[Nancy OShea]

Did you Disable or Edit  code Linting in your Preferences yet?

Nancy

[Silverwulf]

https://forums.adobe.com/people/Nancy+OShea  wrote

Did you Disable or Edit  code Linting in your Preferences yet?

Nancy

Yeah, I gave that a try and it didn't seem to have any effect. From what I understand, linting would have more to do with giving suggestions about improper coding rather than actually rewriting the code, but I could be wrong about that.

[Silverwulf]

BenPleysier  wrote

• For XHTML, <input type="text" disabled="disabled" /> is the valid markup.
• For HTML5, <input type="text" disabled /> is valid and used by W3C on their samples.
• In fact, both ways works on all major browsers.

Even in ColdFusion you will find that

<cfinput type="text" id="txtIID" name="txtIID" value="#txtIID#" class="form-control" disabled>

is the correct format

I'm not disputing that this may be the more correct way to write the code, but since Coldfusion won't let me write this either:

<cfinput type="text" id="txtIID" name="txtIID" value="#txtIID#" class="form-control" #isDisabled#>

and I'm not going to make multiple inputs just to have one be disabled and the other not (for a dozen different reasons on this page that would complicate the situation far too much), the better option right now would be to turn off this unnecessary and unwanted behavior.

[Niharika Jha]

Hi,

We have fixed this issue for the next Dw release, you can verify it now if you are a Dw Pre-release user or you can verify it later when we make the release public.

Thanks for all your support and feedback.

Regards,

Niharika Gupta

Adobe Dreamweaver