I have a weird bug. When I beautify my html/php mixed code it breaks the line and puts the echo and the following tag on 2 different lines making it look ugly.
Anyone had this problem before ?
BTW look at $answer_hash['topic_firstname'] suddenly the following )) are green/commented looks like.
Not sure, my only guess would be that you have softwrap (also called wordwrap) on. You can disabled it at: View -> Toggle softwrap.
To awnser your second question, the value="" attribute normal contains string, and not code. So it gets the green color as if it is a string.
You're using the standard syntax theme that doesn't give a color to parentesis and curly braces, so since it's in a value="" attribute it gets the green color.
It's default behavior of PHP-CS-Fixer (I assume you use the default PHP beautifier of atom-beautify in version 2) to break lines after curly braces.
The body of each structure MUST be enclosed by braces. Braces should
be properly placed. Body of braces should be properly indented.
Scroll down to 'braces [#PSR2, #Symfony]'
Which is defined in the PSR-2 coding style guide:
Opening braces for control structures MUST go on the same line, and closing
braces MUST go on the next line after the body.
If you switch back to version 1 in the atom-beautify settings it won't do the line breaks but it stop fixing other things only available in version 2.
For completeness (although rpm192) has already answered the second part of your question: The )) are green because the standard color for html attribute values is green. Since your document type is set to PHP, all built in functions, arrays etc. between PHP-tags are colored differently but everything else, which does not have a different color specified, keeps it's previous color (which in this case is green). As you can see in the screenshot if you place the PHP-code outside of the html attribute value the braces are colored white as usual.
Note: You have more opening curly braces { than closing ones. Check out line 6 in my screenshot.
Related
I'm using AMP with PHP and when I'm trying the AMP validator (ttps://validator.ampproject.org/) I get a couple of errors that do not make sense become of a BOM character at the beginning of my page.
Example:
URL: https://www.laurentwillen.be/gadgets/xiaomi-redmi-note-7-test-avis-et-prix/
I get the following error: (among others)
The mandatory attribute '⚡' is missing in tag 'html'
If you look at the source of this page, the attribute is there but when you use the AMP validator, there is a red dot appearing at the very beginning of my page.
If I add a letter at the very top of my code like this:
A
<?PHP
// my code goes here
?>
I see the red dot appearing before the letter which highlights that my code is not generating the issue. In Notepad++ I see that the encoding is set to UTF8.
Do you know how I could remove this so that I can work on the real AMP errors?
Thanks
Laurent
I have a little issue with SonarQube to scan PHP code.
When scanning the work, there is an error coming a hundred times:
Move this open curly brace to the end of the previous line
This apply on this code for example:
class Edit extends Container
{
It shouldn't as PSR are clear on this topic :
Opening braces for classes MUST go on the next line, and closing
braces MUST go on the next line after the body.
Opening braces for
methods MUST go on the next line, and closing braces MUST go on the
next line after the body.
Opening braces for control structures MUST
go on the same line, and closing braces MUST go on the next line after
the body
When I look in the detail of the error in Sonar, this is what the rule seems to follow, which is not appropriate:
Sharing some coding conventions is a key point to make it possible for a team to efficiently collaborate. This rule make it mandatory to place open curly braces at the end of lines of code.
And there it shows me the example of the if condition
if(...) {
//...
}
Any idea to follow the proper rule?
Finally I found a solution:
edit your project configuration by disabling the faulty rules and enabling the wanted ones, in this case: PSR2. You can also add some additionnal rules, for example in my case, the Magento 2 ones ;
to make the changes taken in to account: launch a new build.
Hope it will help other.
Since I have many (bad coded/indented) files, that look like this:
After doing a reformat, most code is indented right, but some parts still look like this:
After having a closer look (with sublime) I noticed that these lines are not indented with tabs, but with spaces:
So why are those parts not indented right with tabs?
Additional question: How can I remove the empty lines for the hole project?
The issue with spaces instead of tabs and original indentation -- you need to remove span from the "Keep white spaces inside" list in Code Style for HTML.
Empty lines -- most of them you can get rid if you disable "Keep line breaks" sort of options and put 0 into "Maximum black lines" kind of fields -- there quite a few of them in each language (HTML & PHP in your case).
Unfortunately those options do not seem to have any effect on empty lines between PHP code blocks (between '?> and <?php). For such cases I suggest use regex and replace \n\n (2 line endings in a row) by single \n (you may need to run such replacement few times if you have lots of consecutive empty lines).
First, yes, I know that regex should never be used to parse HTML, however, in this situation I'm taking a long string of text (output of var_dump(), actually) and using several regexes to transform it into XHTML so I know exactly what tags I will be dealing with. The last two regexes in my sequence look for the curly braces and transform into pieces of XHTML. It works great EXCEPT for when the curly braces are contained in a string variable, which I am outputting in between <var></var> tags in a previous regex.
So, currently, I'm using: /\s*{\s*/u. What I need to do is adjust this to ignore any curly brace anywhere within the <var></var> tags.
I've tried using: /\s*{\s*(?!(?<!<var>)[^\{]*<\/var>)/u but that isn't quite right. I have not yet pinpointed what the conditions are that make it not work correctly. So, I may be close with this regex or I may be way off. Hence the need for the SO expertise. Thank you.
Also, if this is simply not possible, there are other hacks I can do, ie, base64_encode() the string, stick it in the <var></var> tags and then as a last regex, base64_decode() anything surrounded by <var></var> tags. I'd prefer to find a usable regex and more importantly, simply curious if it's possible.
This might work:
\s*{\s*(?:(?!(?:.*?</var>))|(?=[^<]+<var>))
Pretty much, I rephrased the question: Instead of not matching curly braces within <var>, I only match curly braces that can be proved to be outside of <var>. So, a curly brace is outside of a <var> if:
It can be asserted that this is true: (?!(?:.*?</var>)), which uses a negative lookahead to ensure that we don't hit the closing </var> tag, or
It can be asserted that this is true: (?=[^<]+<var>), which uses a positive lookahead to ensure that somewhere we'll eventually hit the opening <var> tag.
It will definitely fail with nested <var> tags, but it seems to work with the test case I used. You can run it on RegExr and tell me what you think.
I am editing some code that I've inherited from elsewhere and there seems to be a problem with the script tags in this section of the code. If I remove them the page runs but obviously the javascript does not run.
I'm not too good with php so I'm not sure how to fix this.
$GLOBALS['TEMPLATE']['extra_head'] = <<<ENDHTML
<script src='js/ajax.js' type='text/javascript'></script>
<script src='js/blog.js' type='text/javascript'></script>
ENDHTML;
Just a guess, but if there are any characters (including spaces or tabs) on the same line before or after the closing delimiter of the HEREDOC, you will get errors.
From the manual:
Warning
It is very important to note that the line with the closing identifier must contain no other characters, except possibly a semicolon (;). That means especially that the identifier may not be indented, and there may not be any spaces or tabs before or after the semicolon. It's also important to realize that the first character before the closing identifier must be a newline as defined by the local operating system. This is \n on UNIX systems, including Mac OS X. The closing delimiter (possibly followed by a semicolon) must also be followed by a newline.
If this rule is broken and the closing identifier is not "clean", it will not be considered a closing identifier, and PHP will continue looking for one. If a proper closing identifier is not found before the end of the current file, a parse error will result at the last line.
What you eluded to (blank screen and broken syntax highlighting in your text editor) would be the result or symptom of a parse error if error reporting is off. It's hard to see if this is the case in your post, being outside the context of the actual file.
Check that out and see if it is applicable.
Aside: It's a good habit to turn on error_reporting(E_ALL) while in development.
Those 'tags' just allow you to enter bare HTML within PHP code without having to use quotations etc.
It's assigning anything between those 2 tags to the variable: $GLOBALS['TEMPLATE']['extra_head']