I have a WordPress site hosted with BlueHost. When I FTP on to the server, edit a WordPress theme file and re-upload, I get a white screen with the following error
Parse error: syntax error, unexpected '}' in
/home/challey3/public_html/wp-content/themes/challengers/page-invoice-payment.php
on line 1
The code is being downloaded directly to my hard drive and edited using PhpStorm, I've noticed then when I open the file in PhpStorm there is an additional blank line between each line of code, whereas the additional lines are not present when editing through Notepad.
The changes to the code were adding a jQuery snippet to the HTML and no modifications were made to the PHP itself. Undoing adding the snippet and re-uploading have the same effect, however, if I do a Git revert and re-upload the problem is resolved.
The only thing I can think is that the file is being encoded differently through PhpStorm/Windows and uploading it back to the server is somehow breaking things. The server is running Ubuntu.
PhpStorm does not modify the file during transfer (upload or download).. so it must be server-side (FTP) setting.
As per my knowledge it's about line ending used in that file + specific FTP server config.
My assumption (based on personal experience working with 2 such already "broken" sites + info from other users who faced the same) is that during upload FTP server reacts on CR (used as line ending symbol -- CRLF is what Windows uses) and tries to "fix" it by replacing it by LF.
The FTP server may simply be doing it wrong -- instead of replacing whole CRLF it just does it on CR only.. so you may simply ending up with LFLF (2 line endings in Unix style -- 2nd one makes that extra empty line).
If I'm correct -- try converting that file in IDE to use Unix style LF as line separators first (either via Status Bar (next to encoding) or File | Line Separators).
In any case: here is the ticket in PhpStorm's Issue Tracker -- maybe one day they can offer some better solution: https://youtrack.jetbrains.com/issue/WI-9103 -- watch it (star/vote/comment) to get notified on any progress.
Related
There are a number of similar questions, but none of the answers worked for me.
I'm running Rails 6.0.3.2, Ruby 2.6.6, and SQLite3 on Windows 10 version 2004 (19041.388). I followed the Getting Started guide on the official Rails site to install Ruby on Rails and and everything should be up to date.
I can delete the files normally, and I'm logged in with an administrator account — not that it should be necessary.
I'm new to Ruby and Rails, so detailed answers would be appreciated.
Code
Here's what causes the error:
def destroy
book = Book.find(params[:id])
begin
File.open(book.cover_url, 'w') do |f|
File.delete(f)
end
rescue Errno::ENOENT
end
book.destroy
redirect_to books_path
end
What this does it first delete the cover image for a book and then delete the book itself from the database.
Errors
The error screen:
If the picture doesn't load, here are the error messages:
Errno::EACCES in BooksController#destroy
Permission denied # apply2files - D:/Projects/Web/RoR/ecommerce/app/assets/images/covers/circles_scaling_anim_positioning.png
File.delete(f) is the culprit.
Attempted Solutions
The only actionable answer I could find for Windows was this,
which advocated adding a 'lib' gem, but it did not work at all.
I also tried changing file mode from 'w' to 'wb+', but that didn't
work either.
EDIT 2: As per Dave Newton's suggestion in the comments (if that's what he meant), I moved the image storage directory outside the 'app' folder; to 'public/uploads/covers'. It hasn't worked either.
EDIT 3: I copied the delete code to a new script in another directory entirely and tried it on a sample file. I got the same error. In other words, the problem is not with Rails but Ruby (or my OS).
I called rm on the file from the terminal and that worked just fine, so I don't know if it's a file permissions problem.
EDIT: I checked the file in question and though it still remains, it's 0 bytes large now, so I presume it was overwritten by empty data. However, the rest of the code that should've execuded on destroy — i.e. the destruction of the object in the databse — seems not to have run, because the object is still in there.
The file handling enforced by the operating system is different on Windows compared to most UNIXy operating systems (such as macOS, Linux, or the various BSDs).
On the UNIXy operating systems, the file entry in the filesystem is just a pointer to the "real" file stored on disk. There are other possible pointers, such as a file handle when the file is opened by a process, or a hardlink (i.e. a different filesystem entry pointing to the the exact same file). The file exists on disk as long as there is at least one valid pointer to that file.
As such, on UNIXy systems, you can delete (or rename / move) a file from the filesystem while it is opened from a process. The file itself will only actually be deleted once the last filehandle is closed.
Windows however is more strict in this regard by default. It will not allow to delete a file as long as there is any process which has a file handle on the file (i.e. if any process has opened the file). This explains why you can't delete the file while you have a filehandle on it
With that being said, since Ruby 2.3.0 there is a flag you can set when opening the file which instructs Windows to allow deleting (or moving) the file while it is opened:
# the flags for the normal 'w' mode
file_mode = IO::WRONLY | IO::CREAT | IO::TRUNC
# Add flags to allow deleting (or moving) the opened file
file_mode |= IO::BINARY | IO::SHARE_DELETE
File.open(book.cover_url, mode: file_mode) do |f|
File.delete(f)
end
Note that the IO::SHARE_DELETE flag is only taken into account for files opened in binary mode (rather than text mode) take this into account when working with this opened file. On UNIXy systems the IO::SHARE_DELETE is ignored.
There is some documentation of the various flags available.
As a final remark: I assume that your code is a shortened example where you have left out some code actually interacting with the opened file in addition to deleting it.
If all you want is to delete the file, there is no need to opened it first. Just delete it with File.delete(book.cover_url). Alternatively, if you you don't care for any errors (such as if the file doesn't exist in the first place, you can also use FileUtils.rm_f(book.cover_url).
Changed the code to this...
begin
File.delete(book.cover_url)
rescue Errno::ENOENT
end
...and it works now. No opening any files; just File.delete(URL).
If anyone knows why the original version didn't work, or why it's so commonly suggested, please post an answer or comment on this answer.
This question is being asked as part of the CKEditor forum apparently now hosted on stackoverflow. I am treating this entry as a forum question. I hope it will appear in the correct place on the stackoverflow site. Please advise if it should be redirected.
I am using the filebrowserImageUploadUrl config setting in a ckeditor instance.
In Firefox or Chrome, when I click on the "Upload" tab to view images on the local device, select one, and click "Send it to Server," the value transferred to the server by ckeditor is simply the file name and extension. The url saved and returned is correct, and all works fine.
In IE11 (and earlier?) and the new MS Edge, the filename sent to the server is the full path name stripped of all "\" separators. So, for example, the file on a Windows PC named "C:\Users\username\Pictures\imagename.jpg" is sent as "C:UsersusernamePicturesimagename.jpg".
I verified this by simply returning the string "upload.FileName" in the ckeditor dialog callback, where "upload" is the first parameter in the transmitted transaction and is declared on the server in C# as a HttpPostedFileWrapper. The returned value in Firefox and Chrome are the filename.ext, while in IE and Edge, it was the stripped full path name described above.
Any ideas on why this might be the case? Is there a known process/protocol for detecting this difference and dealing with it?
I forgot to mention that I am using ckeditor 4.5.3 (latest as of this writing). The problem also occurs in release of 4.5.1 (earlier development).
The file name parameter sent to the server by ckeditor's upload (using various browsers for an MVC 5 website in Visual Studio 2015) turns out to be (1) only the filename.ext in Firefox, but (2) the full and correct file name in IE, including the "\" path separators.
So this is not a ckeditor issue. It is instead a choice in browser security settings and/or defaults. I am not sure what the IE default is (full path in my IE is disabled when I launch it directly, but is enabled when IE is used as the browser launched in Visual Studio). So, obviously, the file name has to be parsed out of the path on the server side if and when the full path is provided.
Here are the two operative lines of C# MVC code that solved the problem (surrounded by some write's). The controller does not assume what's coming. If only the filename.ext is transmitted, that's what ends up as the ImageName. If the full path, it parses it down to the filename.ext.
public ActionResult ControllerName(HttpPostedFileWrapper upload, string CKEditor, string CKEditorFuncNum, string langCode)
{
. . .
System.Diagnostics.Debug.WriteLine(upload.FileName);
string ImageName = upload.FileName;
System.Diagnostics.Debug.WriteLine(ImageName);
ImageName = System.IO.Path.GetFileName(ImageName);
System.Diagnostics.Debug.WriteLine(ImageName);
. . .
}
Using the writeline code, I was able to confirm the received value (either filename only or full path) and that the parse worked when needed but did not change the value when only the filename.ext was transmitted.
I hope this learning will be useful to others. Sorry for the false alert.
So for a while now almost every file I open (html/css/php) has two line-breaks instead of just one. I attached a screenshot of my Notepad++ where you can see what is happening. If I open these files in Notepad they show like they should. However Notepad++/Netbeans/Sublime all leave me hanging. Any ideas?
http://snag.gy/6aLrI.jpg
There are 3 types of line terminators for text files:
Carriage return (0x0D) + line-feed (0x0A) for DOS/Windows text files.
Only line-feed (LF) for UNIX text files.
Only carriage return (CR) for MAC text files (prior OS X).
See also Wikipedia article about newline.
The preferred line terminator type on UNIX web servers is LF only, but most text files for web sites are edited on Windows. Therefore all FTP clients have the option to transfer text files either as ASCII or as binary.
Option ASCII means the FTP client inserts CR before each LF in file on downloading a text file from server. And each CR before LF is removed on uploading a text file to the server. So a text file stored on UNIX web server with just LF is converted on download to DOS/Windows and converted back on upload to UNIX. The binary transfer mode results in downloading/uploading the files without any modification by the FTP client.
In your screenshot I see in status bar at bottom Macintosh which is an indication that the file is handled as a MAC text file. The reason is most likely that on server the *.php files are stored already with DOS/Windows line terminators (CR+LF) and on download nevertheless the ASCII transfer mode is used resulting in text files having CR+CR+LF. The text editors now do not know how to correct handle those text files - as MAC files with an invalid LF or as DOS files with an invalid CR. Your text editors interpret the files as MAC files with invalid LF and therefore a newline for first CR and another one for CR+LF.
Solutions:
Select binary transfer mode in your FTP client to download/upload the DOS/Windows text files without any further modification by FTP client, or
search for \r\r\n on downloaded files and replace all occurrences with \r\n to get finally DOS/Windows text files on local disc and UNIX files on web server after upload.
I am having some issues with Coda 2. I work in a hybrid Windows/Mac environment and I am on a mac running Coda 2 to do my development work. After hitting Command , I set my default File Encoding to Unicode (UTF-8) and my Default Line Endings to Windows. Yet if you open one of my files in Notepad++ on a Windows environment it says that the file was saved with UNIX end-of-line characters.
Any ideas on how to get around this? I have done some research online and everybody seems to think that once these options are set that I should be fine, but it's not...I am running Coda 2.0.9
It appears that the only time this happen is when I send an HTML file via email. If I sent that file as a zip file it is fine, or if I load it to an FTP location it's fine. Not coda's fault at all.
I hava an application that reads a file from a ZIP archive and saves it to file on file system. After writing it to file system I start start immediately to read this file with a SAX2 reader. On bigger files (300+ MB) it sometimes occures, that SAX2 stops parsing because of an unclosed tag. But when I check the file (or even try to read it again later) it works, so the file it self it OK.
FZipKit.ExtractToStream(LFileName, LStream);
LStream.SaveToFile(OutputFilename);
SAX2.processUrl(OutputFilename);
My assumption is, that the file was not yet fully written to file system when I started the parsing process.
Is there a way to ensure, that the file was written or the steam has been flushed to file system?
thx
I'm going to first of all assume that the XML parser operates correctly. If it is incapable of reading files, well the solution is obvious.
Which leads us to look at how the file is created. When you call SaveToFile, the file is opened, written, closed and buffers are flushed. In a plain vanilla system, your XML parser will see the entire content of the file. The only conclusion is that something is interfering. The most like suspect is your virus scanner. Many scanners, even the most respected ones, cannot properly handle a file being closed and then immediately re-opened.
The bottom line is that your code is fine and the problem almost certainly lies with your local environment.