Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID

elefant update error

edited October 2014 in Framework

Trying to run elefant update, I'm getting Error: Unable to fetch file. releases/1.3.json

Comments

  • I updated instead from github, which caused elefant to show a click to update button in the browser. When I clicked, I got an SQL error because MySQL doesn't like the default '' for the text field about in the user table.

  • I just pushed a change that gets rid of the default value for about. Let me know if that fixes it.

  • Yup, it fixed it. Thanks. Do you know what the other error (Error: Unable to fetch file. releases/1.3.json) is about?

  • Looks like Github's raw urls have changed to raw.githubusercontent.com instead of raw.github.com. I just pushed an update, unfortunately that doesn't really help with existing sites since it pertains to the updater...

  • Yeah, quite a Catch 22!

    I have a (hopefully sensible and easy to implement) request. Would you consider configuring your text editor to add an EOL character to the end of text files? It would clean up my (and maybe others'?) git diffs. http://robots.thoughtbot.com/no-newline-at-end-of-file

  • What do you think about omitting the closing tags instead? Extra white space can cause issues after closing tags, so maybe it's time I unlearn the habit of always including them... :P

  • I think we're talking about two different things. (?)

  • What I mean is that I'd probably include an EOL character if it weren't for the closing PHP tag, which I usually try to avoid having any extra characters after. So when I use closing tags, I prefer not to have an extra EOL on the chance that extra whitespace could sneak in there and mess something up.

  • I see. As I understand it, it's not really an extra EOL character -- it's just the line feed at the end of the last line. There's not actually any white space below the closing tag.

    Without EOL:

    Without EOL

    With EOL

    With EOL

    However, I guess some editors show it as white space below the last line. Discussions: One Two

    But I would take the PHP closing tag over the EOL character if I had to choose one or the other.

  • Back to the default value for about: I don't have an about field on my signup page, so I get Error creating profile: SQLSTATE[HY000]: General error: 1364 Field 'about' doesn't have a default value

    Not hard to add about to the handler, but I mention it because I believe the default elefant user signup form also doesn't include the about field.

  • Do you mean you'd prefer to keep the closing tags over having an EOL character at the end? If so, why is that?

    I'm kind of leaning towards getting rid of the closing tags in .php files at some point, since that's what the PHP manual recommends, and only haven't because I've been in the habit of including them for so long.

  • Ah yes, the about not having a default value breaks the user/signup form. I've been using SQLite too much these days... Just added an empty about field to user/signup and user/login/newuser (for social logins).

  • Do you mean you'd prefer to keep the closing tags over having an EOL character at the end? If so, why is that?

    Well, I hadn't really thought about the closing tag issue, so I don't really have an opinion about that (other than a reflexive "if it's been opened, it seems good if it's closed").

    The line ending thing affects me more because I use linux on my work computers and linux tools expect text files to end with an EOL. In particular, the way I update elefant is to pull the changes into a mirror on my machine and then run a script to find differences in my sites (to make sure I don't overwrite any hacks I might have made to core files). Currently, that script reports every EOL/no EOL difference as an actual change, so there's a lot of noise.

  • I think getting rid of the closing tags and requiring the last line of all .php files to be an empty line (which is in line with the PSR standard, although I diverge from it on a few other things like tabs) should solve the noisy diff issue.

    I should be able to remove them all with a quick shell script.

  • Still not sure if we're talking about the same thing because they don't display with an empty last line for me.

    It's not only .php files -- it's any text file. This is the quick and dirty command I'm using at the moment to add the final EOL: find . -type f -name '*.php' -o -name '*.html' -o -name '*.css' -o -name '*.txt' -o -name '*.js' -o -name '.htaccess' | sed -i -e '$a\'

  • I haven't checked every .css or .js file, but I removed the PHP closing tags and ensured all layout and view templates as well as .php files should have an EOL now. I'm usually in the habit of including an extra newline at the end of my .css and .js files already, so most are probably okay too :)

  • Thanks, I'll check it out this weekend.

  • OK, I checked it out and all the .php and .html files work perfectly now. I still get diff variations for .css, .js, .txt, .sql, and .htaccess files. Examples:

    diff tests/.htaccess $CLIENT/tests/.htaccess 
    4c4
    < </Files>
    \ No newline at end of file
    ---
    > </Files>
    
    diff apps/user/css/details.css $CLIENT/apps/user/css/details.css
    27c27
    < }
    \ No newline at end of file
    ---
    > }
    
  • Upon further checking, the .php files in lib/vendor and the .html files in apps/cli lack EOLs. Also a couple other places, but it's much cleaner now, so thank you.

  • Re: default value for about: Would it be good to add it to user/add, too? (Just ran into this.)

  • Re: the github url: if we change the url in apps/cli/lib/Updater.php can we run the updater safely?

  • I believe so!

Sign In or Register to comment.