Edit php.ini (For newer Redhats, that's /etc/php.ini)

Find the "file_uploads" line.

Change it to:

file_uploads = On

Restart apache.

Relax and enjoy!

-cw-

I had already file_uploads = On ... and it doesn't work. I have an Admin who can and another Admin who can't preview/save on the same geeklog same database and file_uploads = On, of couse

This was already posted as a comment to <a href="http://www.geeklog.net/article.php?story=20020610222639993#comments">the original thread about the Save/Preview problem</a>. Its not a fix, it might have worked in your case, but its not a universal solution. <p> Something wacky is going on.

Sounds like there may indeed be other issues of a similar nature, involving other OS'es or environments. However, what I hit against is very repeatable and very fixable. It may be *only* a stock RedHat 7.3 thing, I don't know. But sure as the sun rises (or the planet revolves, if you want to get technical , other folks running stock RH7.3 are going to smack right into this, and here's why: It seems that with newer versions of PHP, the feature that allows uploading (i.e. HTTP POST) of files can be switched off. For at least PHP v4.1.2 that comes with RH7.3, the default setting for file uploads is in fact "off". Without this feature turned on, HTML form posting that uses enctype="multipart/form-data" simply doesn't work. The posted vars get "lost" basically, and are not available in the target script. So guess what encoding type is used by the preview/save/delete/cancel functionality in the public_html/admin/story.php module? Yup, multipart/form-data. That's because the story.php form in question allows posting of image files along with the story, and multipart/form-data encoding is required for that to work. I went through countless iterations with the "file_uploads" setting in php.ini, along with various combinations of adding/removing the enctype attribute from the FORM tag in public_html/layout/clean/admin/story/storyeditor.thtml (note I was using the "clean" theme...) and ultimately concluded that there is a very direct and very certain relationship between the file_uploads setting, the enctype attribute, and the "bug", where clicking on Preview/Save/Delete story all behave the same as clicking Cancel. I'm truly sorry if other folks are experiencing a different but similar problem. It is my hope that detailing this problem will at least provide a clue or two about the other issues. Please forgive me a really stupid question: For anyone who had to actually turn on file_uploads, did you remember to restart Apache? That was yet another necessity I learned the hard way... -cw-

Mi instalation worked fine (SUSE 8) I had 2 admin (all permissions boxes checked). I had file_uploads = On from the begining and Geeklog worked FINE! (for a month)

Now (yes, suddenly, I've not installed anything), one of my admin can't save preview histories.

For me this was the fix, just as you described. Great, everything woring again. Thank you, Robert de Bock.

I've said it before, I'll say it again. File_uploads = on is a security risk for some version of PHP:

PHP remote vulnerabilities

Can anyone confirm if they are able to edit stories on a GL 1.3.5sr1 installation using an older PHP (i.e., php 4.0.x) with "file-uploads = off"? The security issues with older PHP versions and "file_uploads = on" are too significant to ignore. If the enctype=multipart/form-data is removed from the storyeditor.thml in each theme, the abiliity to edit returns, however the image upload is lost.

Yes I read it. I'm just not in a position to be able to provide direct help with a problem I'm not having. All I could reasonably do is provide more detail about what I smacked up against, in the hope that it might be useful, even if just to show that they are two unrelated problems. I was also hoping that a little detail on what I did to track down my problem might be generally useful to others having even less GL/PHP experience than I. -cw-

(That speed limit thing strikes me as more PITA than anything else, but anyway...)

Good point, and it serves to highlight that you should always be up to speed on security issues for any 'net connected software you are running. If not that, then at least be sure you are always running the latest, greatest versions.

Really, if you aren't keeping up with security alerts and/or running the newest versions, a vulnerable PHP may well be the least of your problems. Other network-oriented software like ssh, ssl, sendmail and login have all had serious security issues recently -- many with known exploits. (I had one of my own boxen r00ted last November via a vulnerable version of sshd.)

For the really paranoid, you should not only be checking the security sites daily, but also run Nessus, or something like it to scan your boxen on a regular basis.

-cw-

Well since no one else jumped in... Near as I can tell, multipart encoding and file uploads go hand in hand. At the very least, I would not expect to be able to upload images (which are files, after all) with file_uploads = off. Anyone know different? -cw-