New to PHP and changed some code further down than line 1 on a WordPress site.
Using Dreamweaver CC to upload. Getting:
Parse error: syntax error, unexpected T_IF in
/home/jodyrein/public_html/www.writersblogfinder.com/wp-content/themes/rockthebook/functions.php
on line 1
at www.writersblogfinder.com
Here is the first few lines of code:
<?php
/**
* rockthebook functions and definitions
*
* #package rockthebook
*/
/**
* Set the content width based on the theme's design and stylesheet.
*/
if ( ! isset( $content_width ) )
$content_width = 640; /* pixels */
Check that you have not edited your file using a horrible editor, like notepad. Your if() statement is reported as line 1, prrobably because of the lineends. Save the file in another editor, that uses newline instead or carriage return.
I've had similar problems before with hidden/non standard characters creeping into the file thanks to bugs / quirks in the editor. Best thing to do - copy the whole lot of the code into something like notepad (PC) or textmate (mac) and save the file out again, re-upload and re-test it... usually resolves it for me.
Seems Dreamweaver was loading the php text all as one line. I pasted the php into the Wordpress editor and and it's fine
copying to Notepad editor saving and uploading fixed my problem.
I just wanted to mention after hours of trying to figure this out, re-saving from Notepad worked!
I use Sublime Text 3 as my daily text editor, so I find it quite odd that this issue wasn't being picked up, but copying the code from ST3, pasting in to Notepad and then saving over functions.php fixed the error.
I should also note that I was only seeing this error on the server, not on my localhost.
Thank you for this advice!
Related
I am reading book/documentation in Vim written in rst (reStructuredText) format. Book is about PHP, so it is full of code. If I manually set filetype to PHP, code has syntax highlight.
set ft=php
But if place this line in my .vimrc, filetype is reckognized by vim, but there is no code syntax highlighting.
au BufRead,BufNewFile,FileType *.rst set ft=php
Anybody knows how to fix that ?
Thanks
Redirecting all reStructuredText files to show up as PHP looks wrong. Instead of messing with the filetype detection, I would rather explicitly specify the filetype:
:edit +setf\ php phpbook.rst
If there are several files, and this is permanent, I'd configure this path-based:
:autocmd BufRead,BufNewFile /path/to/dir/*.rst setf php
Alternatively, you can use one of the local vimrc plugins; there are several on vim.org; I can recommend the localrc plugin, which even allows local filetype-specific configuration.
Alternative
With my SyntaxRange plugin, you can keep the default reStructuredText syntax, and only mark the PHP snippet sections as PHP:
:12,42SyntaxInclude php
If the sections are delimited by certain patterns, this can even be automated.
I have a weird PHP error in a current Symfony2 project:
unexpected T_STRING in /blahblah/Foo/BarBundle/Entity/User.php on line 1
This is a pretty standard error, usually linked to a mismatched pair of " or '.
But here is the code of the file User.php
<?php
namespace Foo\BarBundle\Entity;
use Doctrine\ORM\Mapping as ORM;
/**
* #ORM\Entity
* #ORM\Table(name="fos_user")
* #ORM\Entity(repositoryClass="Foo\BarBundle\Entity\UserRepository")
*/
class User extends \FOS\UserBundle\Entity\User
{
// classic user entity
The line <?php is line #1. There is no quotes, and the weird thing comes from the fact that this error only appear on my staging server: on 2 development machines with local copies of the code, it behaves as expected with no error or warning.
The file is the correct one, the cache was emptied. I thought that it might be an encoding error but it does not seem to be this. I also thought of namespace issues, but the PHP version on the server is correct (5.3.16)
Do you have any idea what this error can stem from, or in which direction I could search ? Thanks in advance.
Most coding conventions that I worked with strictly require using LF ('Unix style', '\x0A') line endings in the scripts. And whoever managed to submit code with CRLF or, god forbid, CR had to endure a royal share of pain. )
It may seem not such a big deal, yet it can save you hours of searching for a weird error - such as in this case.
I think it's an encoding problem of your file. If your project is encoded UTF8 for example, open your file with your text editor and choose the option "Encoding" -> UTF-8 without BOM.
I have a PHP site and a cron job which runs to update the DB for the site. The cron reads a CSV file which is uploaded by a third party. Recently this cron job stopped working correctly. After some investigation, I've discovered that the problem is in the CSV file. The problem is that the new line character in the CSV has changed from the standard "\n" to the older ASCII "^M" and PHP doesn't seem to recognise this as a new line so instead of seeing the CSV as multiline, it is seeing it as one single line of info. I have only been able to see this difference in the Command Line text apps less and vim. Does anyone know of a way to get PHP to recognise these new line characters?
By way of an example, the incorrect CSV file looks similar to this in vim:
Heading 1,Heading 2,Heading 3,^MInfo 1-1,Info 1-2,Info 1-3,^MInfo 2-1,Info 2-2,Info 2-3,^M^M
Whereas the older (correct) version displays like this in vim:
Heading 1,Heading 2,Heading 3,
Info 1-1,Info 1-2,Info 1-3,
Info 2-1,Info 2-2.Info 2-3,
Set the auto_detect_line_endings option appropriately.
Can you not change your code to look for ^M or replace ^M with \n?
str_replace("^M", "\n", $input);
I work home with Dreamweaver cs5 on windows 7 and on work on windows xp Dreamweaver cs5.5
When i edit file home and open it from ftp on my work all spaces between lines of code double when i get home and open file there are additional space line added to each empty line why is this happening?
e.g.
if (true) {
test();
};
now looks like
if (true) {
test();
};
and this is everywhere.
Also sometimes rarely i open file and my php code does not have no new lines its all on the same big line like this.
if (true) { test(); };
Someone knows whats the problem here?
Maybe it will be not best answer, but...
Dreamweaver is wrong tool, use normal IDEs - PhpStorm or NetBeans.
Open the file
Click CTRL + F
Select "Current document" in "Find in" (You can also select the
folder if you have multiple files)
Search in "Source code"
Tick "Use regular expression"
Type "[\r\n]{2,}" (without quotes) in "Find"
Type "\n" (without quotes) in "Replace"
Press "Replace All"
This is something that does come up with Dreamweaver and it happens when you're on a Windows machine and you download a file from a Unix server.
There's a fairly easy fix to immediately get rid of the extra line breaks at least, if that's the current issue, and to prevent them in the future:
http://www.jaredstenquist.com/2009/02/13/removing-extra-linebreaks-and-spaces-in-dreamweaver/
When removing extra line breaks, it will remove all empty breaks so be sure this is what you want - you may have to create some manual breakss over again.
As for line breaks not appearing in rare cases, I suspect setting line break type to match your sever's as suggested in that article may address that issue as well.
I'm trying to debug a plugin-bloated Wordpress installation; so I've added a very simple homebrew logger that records all the callbacks, which are basically listed in a single, ultimately 250+ row multidimensional array in Wordpress (I can't use print_r() because I need to catch them right before they are called).
My logger line is $logger->log("\t" . $callback . "\n");
The logger produces a dandy text file in normal situations, but at two points during this particular task it is adding something which causes my log file to no longer be encoded properly. Gedit (I'm on Ubuntu) won't open the file, claiming to not understand the encoding. In vim, the culprit corrupt callback (which I could not find in the debugger, looking at the array) is about in the middle and printed as ^#lambda_546 and at the end of file there's this cute guy ^M. The ^M and ^# are blue in my vim, which has no color theme set for .txt files. I don't know what it means.
I tried adding an is_string($callback) condition, but I get the same results.
Any ideas?
^# is a NUL character (\0) and ^M is a CR (\r). No idea why they're being generated though. You'd have to muck through the source and database to find out. geany should be able to open the file easily enough though.
Seems these cute guys are a result of your callback formatting for windows.
Mystery over. One of the callbacks was an anonymous function. Investigating the PHP create_function documentation, I saw that a commenter had noted that the created function has a name like so: chr(0) . lambda_n. Thanks PHP.
As for the \r. Well, that is more embarrassing. My logger reused some older code that I previously written which did end lines in \r\n.