Copy link to clipboard
Copied
If I have the following formatted as it is as I don't want any extra spaces inside the textarea:
<textarea name="someVariable" id="someVariable" rows="10"><?php echo $someVariable; ?></textarea>
I want to do code formatting on entire document but it turns above into:
<textarea name="someVariable" id="someVariable" rows="10">
<?php echo $someVariable; ?></textarea>
which adds unwanted white space inside the textarea field. It adds a line break, 3 tabs, line break, two tabs inside the textarea. How can I prevent this from happening while still being able to use code format?
I looked in the Edit > Preferences > Code Format > Tag Libraries > HTML tags > textarea and have:
Line Breaks: No Line Breaks
Contents: Not Formatted
I looked in the Edit > Preferences > Code Format > Tag Libraries > PHP tags I have the following for everything:
Line Breaks: No Line Breaks
Hi,
I was able to get the issue correctly this time, we will fix this soon for textarea, although we would need to find out more tags where there are spaces getting applied explicitly (if any exist).
As stated earlier, the customization for PHP source formatting can't be done through tag libraries that is why in a php file if you are applying any rule that will be ignored in this case.
So, now we have a bug and an enhancement request.
Regards,
Niharika Gupta
Adobe Dreamweaver
Copy link to clipboard
Copied
Is this in CC2017 or an older version?
Is this after you use the Apply Source Formatting option, or is it being generated by the auto-indentation function as you add the code?
Copy link to clipboard
Copied
In CC2017, when I write the code it stays as desired but after going to Edit > Code > Apply Source Formatting (which I want to do for the rest of the document) it adds the white space.
Copy link to clipboard
Copied
Apparently, the Brackets code editor knows better than both of us.
I can confirm the same incorrect formatting on Apply Source Formatting with the settings and code you've used.
CC2015 works correctly, CC2017.1 re-formats with incorrect line breaks and indentation.
Copy link to clipboard
Copied
https://forums.adobe.com/people/Jon+Fritz+II wrote
Apparently, the Brackets code editor knows better than both of us.
I can confirm the same incorrect formatting on Apply Source Formatting with the settings and code you've used.
CC2015 works correctly, CC2017.1 re-formats with incorrect line breaks and indentation.
Not to state the obvious here, and not wanting to get into any disagreements. The thing to remember is that Brackets is an open source project, written by people who included features the way they wanted them to work. Unfortunately, and if like me you find that some very important features do not work the way one wishes, then there is only two alternatives, go back to an older version of Dw, (and file a feature request for 2017, in the hope it will be 'fixed' at some point) or find a new program to use.
Finding a new program is easier said than done though, and there are so many problems with Dw 2017 that it may take the team more time than one can give them, to fix the problems. Also given that the Brackets code editor and Dw's code editor are the same, and intended to stay in sync from now on, any changes in one should be reflected in the other, doubling the problems for the team.
Copy link to clipboard
Copied
Hi,
We did not support "PHP Code Formatting" in CC 2015, there was only HTML Code Formatting supported in that version so your php code would never move/change from what is written,that means you can not take it as the baseline for comparison.
Since Code Formatting is a convention and not a standard, it varies from user to user and editor to editor. Until and unless, the option- "Apply Source Formatting" doesn't break your syntax, it is not a bug and in your case it doesn't. We have always given an option to customize how formatting should apply for HTML through tag libraries, so what we can now do is we can give an option to customize it for PHP as well.
I have already shared this enhancement request with the team, will see if this can be picked up for fixing.
Regards,
Niharika Gupta
Adobe Dreamweaver
Copy link to clipboard
Copied
I may not have explained this properly, let me try and clarify.
Seems to me either the spaces being inserted inside the textarea form field when I click Edit > Code > Apply Source Formatting are being applied due to formatting defined in the tag libraies for HTML textarea or PHP echo.
For HTML at Tools > Tag Libraries > HTML tags > textarea I have:
Line Breaks: No Line Breaks
Contents: Not Formatted
yet issue still appears, should it have been corrected with those settings?
For PHP at Tools > Tag Libraries > PHP tags > php echo
I have php echo and all other PHP tags set to No line breaks which shows text<?php echo ... >text as the example which is what I want (well actually I want <textarea><?php echo ... ?></textarea> if it makes a difference so maybe this is what is not supported?), yet it still inserts the breaks before and after the php code when inside a textarea. Should it have been corrected with those settings?
Copy link to clipboard
Copied
Hi,
I was able to get the issue correctly this time, we will fix this soon for textarea, although we would need to find out more tags where there are spaces getting applied explicitly (if any exist).
As stated earlier, the customization for PHP source formatting can't be done through tag libraries that is why in a php file if you are applying any rule that will be ignored in this case.
So, now we have a bug and an enhancement request.
Regards,
Niharika Gupta
Adobe Dreamweaver
Copy link to clipboard
Copied
Hi, I know this is a late reply but wanted to thank you for your efforts in identifying and fixing the issue of unwanted spaces around php code inside a textarea. I am not aware of any other tags where there are spaces getting applied explicitly but will let you know if I come across any.
Copy link to clipboard
Copied
Hi Niharika, I don't know if a fix for this bug was ever made but if so just thought I'd let you know the issue still exists in ver 18 build 10136.
Copy link to clipboard
Copied
Hi,
Thanks for coming back, but due to the MAX release new features and other critical bug fixes we could not take this up, we will try and prioritize this for the next update.
Regards,
Niharika Gupta
Adobe Dreamweaver
Copy link to clipboard
Copied
Understood, I will look forward to checking the next update.
Copy link to clipboard
Copied
Hi,
Thank You for your patience.
This issue has been fixed and will be available in the upcoming releases.
Regards,
Niharika Gupta
Adobe Dreamweaver
Copy link to clipboard
Copied
Hi,
The issue has been fixed or not yet?
Dreamweaver CC2017 - Apply code formatting add line breaks.mp4 - Google Drive
https://drive.google.com/open?id=17e3JiiCOjMKM5G7fY0SOppcQnyhc_Q7a
Best regards,
Thierry
Copy link to clipboard
Copied
Hi All,
We are happy to inform you we have addressed a couple of PHP source formatting issues in our latest pre release drop 15073.
Please give it a try and share your feedback.
Let us know if it fixes your issues.
Please find the pre release invite link Adobe Prerelease
Thanks
Dreamweaver Team
Copy link to clipboard
Copied
Hi All,
We are happy to inform you we have further stabilized the PHP source formatting issues in our latest prerelease drop 15081.
Please give it a try and share your feedback.
Let us know if it fixes your issues.
Please find the prerelease invite link Adobe Prerelease
Thanks
Dreamweaver Team
Copy link to clipboard
Copied
Hi,
we are happy to inform you that we have fixed a couple of bugs in our latest Prerelease drop 20.0.0.15092.
Please give it a try and let us know if your issue is fixed and share your feedback.
Prerelease Invite link:
https://www.adobeprerelease.com/beta/9EB451B5-D2E8-46E5-AFA2-78C85442FFA2/participate/DD4EB148-308D-...
Regards
Dreamweaver Team
Copy link to clipboard
Copied
Hi,
we are happy to inform you that this bug is fixed in our latest release 19.2.0.11274 which can be downloaded from creative cloud.
Please give it a try and let us know if your issue is fixed and share your feedback.
Regards
Dreamweaver Team
Copy link to clipboard
Copied
Here's an easier one to see.
1. In CC 2017, copy this .php document and view it in a browser. Pay particular attention to where the words "hi" appear in the <textarea> tags...
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Untitled Document</title>
</head>
<body>
<textarea name="someVariable" id="someVariable" rows="10"><?php echo "hi" ?></textarea>
<textarea>hi</textarea>
</body>
</html>
2. Change the settings for <textarea> in the Tag Libraries to...
Line breaks: No Line Breaks (code should not drop to next line)
Contents: Not Formatted (content should not format or indent)
3. Change the echo and php echo under PHP tags to...
Line breaks: No Line Breaks (no dropping to next line)
4. One would assume this will make it so there are no line breaks or formatting occurring within <textarea> tags, especially if that content were a PHP echo statement, hit Apply Source Formatting.
You will see the lines...
<textarea name="someVariable" id="someVariable" rows="10"><?php echo "hi" ?></textarea>
<textarea>hi</textarea>
...change to...
<textarea name="someVariable" id="someVariable" rows="10">
<?php echo "hi" ?>
</textarea>
<textarea>hi</textarea>
...the <textarea> with html contents have not been changed, as expected, however the <textarea> with PHP contents have seemingly ignored the settings in the Tag Libraries completely.
5. Save the changed file
6. Preview in browser again, notice the display of the <textarea> with PHP content has changed.
With the formatting rules for PHP being ignored by CC2017, the display of the content created by the echo changes because of the added white space within that <textarea> tag.
Since CC 2015 didn't have formatting options for PHP specifically, it correctly followed whatever was set in the Tag Libraries for the <textarea> tag. In this case, not dropping the content to the next line or indenting it.
Now that CC2017 has the ability to modify PHP formatting, it appears to be following its own rules and not what the user actually sets.
Surely, the program ignoring a user setting should be considered a bug, and not an enhancement request, shouldn't it?