Check to see if /concrete5/elements/files/upload_single.php was not removed. And turn on errors to see if there are any warning errors given on the page.

samething happened to me!!! how do i check if the upload php was deleted?

Ok, that was the problem, how do I get it back? Where can I find a copy of the coding that is suppose to go on that page? I can just manually make it & copy & paste the coding.

@josiebaby - you can just download a clean version of concrete5 and take the file from the fresh download and ftp it back to the server.

@poshpiglet - I suggest turning errors on and posting what you see. To turn on errors go to the dashboard, click Sitewide Settings. Then on the top tabs click on Debug. There are radio buttons and click on the one that says "PHP errors and database exceptions will be displayed" NOT suppressed. Then go to that page and see if there are any errors that display. This will give more information to what exactly happened.

# concrete5 Version
5.4.2.1

# concrete5 Packages
Amiant Image Gallery (0.1.8.2), Anticipated (1.0), Black Accents (2.0), Clicky Web Analytics (1.2.0), Eloquent (1.0.2), Evolutium Theme (1.0), Fancy Ajax google search functionality (1.0), Galleria image gallery (2.0), Google Docs Viewer (1.0), Google Plus One (1.0), googlesearch (1.1), Html5 Video (1.0.1), Image Caption (1.5.1), Like Button (1.0), Likes This! (1.0), OAF_Silvery (1.1.3), Personalized Hello (1.1.1), Random Image (1.0.1), Rigid Light - Theme (1.0), ShareThis (1.0), Simple Facebook Gallery (1.01), Splash Theme (1.0), Stickies (1.2.3), TerraFirma2 (1.0), Twitter Search Block by David K Uspal (1.0), Yosemite (1.0), YouTube Background FREE (1.0), Zoom Image (1.0.2).

# concrete5 Overrides
None

# Server Software
Apache/2

# Server API
cgi

# PHP Version
5.2.17

# PHP Extensions
bcmath, bz2, calendar, cgi, ctype, curl, date, dba, dbase, dom, exif, filter, ftp, gd, gettext, hash, iconv, imap, json, libxml, mbstring, mcrypt, mhash, ming, mysql, mysqli, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, posix, pspell, Reflection, session, SimpleXML, sockets, SPL, SQLite, standard, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib.

# PHP Settings
log_errors_max_len - 1024
max_execution_time - 5
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
memory_limit - 18M
post_max_size - 8M
safe_mode - Off
safe_mode_exec_dir - <i>no value</i>
safe_mode_gid - Off
safe_mode_include_dir - <i>no value</i>
sql.safe_mode - Off
upload_max_filesize - 2M
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
pcre.backtrack_limit - 100000
pcre.recursion_limit - 100000
session.cache_limiter - nocache
session.gc_maxlifetime - 7200
safe_mode_allowed_env_vars - PHP_
safe_mode_protected_env_vars - LD_LIBRARY_PATH



this is what i see

josiebaby, what version of concrete5 are you using? have you upgraded recently?

I have 5.4.2.1. I checked another install of concrete5 for another client & she doesn't have the upload_single.php file but her site is just fine, everything is there...do you have another suggestion?

WAIT!!! I have the file!!! I was looking in the wrong place...well since I have the file...why isn't it working properly? Sorry for the confusion.

Glad you found it-- I would be surprised if it was actually missing. It's a core file, and I can't think of any reason it would get intentionally removed.

The first things I'd try:

1) clear your broswer cache.

2) clear your site cache from Dashboard > Sitewide Settings > Speed Settings > Clear Cache.

I've seen a few mentions of this issue but it's certainly not happening to everyone. If the suggestions above don't shed any light on the issue, send me a private message (do NOT post to this public thread!) with a link to your site and your admin login & password and we'd be happy to take a look at it.

Thanks for the Post, Cleared My Cache, and VOILA!! the Upload button is back on there.

I can confirm this was the problem on one of my 5.4.2.1 concrete5 sites. Adding the file types fixed it. Odd though that it only happened on one of my c5 sites. Another one, also running 5.4.2.1 didn't have this problem. In any case, it's working now. thx

Hi doranb,

Are the two sites on different hosts? Did you use a one-click installer like SimpleScripts or Installatron? Our early research into this suggested it was a problem with a one-click installer or automatic upgrade (through the installer). Any details you could pass along would help us track down the issue. Thanks!

Hi Matt,

The two sites are separate installations on the same host (Win 2003 Server SP2). Each was initially installed using the MS Web Platform Installer, which currently installs version 5.4.1.1.

I updated them myself through Dashboard/System & Maintenance/Update. The site which did *not* have missing file extensions is slightly older than the other and was originally updated from 5.4.1.1 to 5.4.2, and then to 5.4.2.1. The site with the missing file extensions was update directly from 5.4.1.1 to 5.4.2.1.

After posting my earlier reply I checked a third c5 site I have set up on a non-public test server. It too was updated from 5.4.11.to 5.4.2 to 5.4.2.1, and the file extensions were *not* missing on it either. It's also a Win 2003 SP2 machine and c5 was installed with the Web Platform Installer.

So of the three, only the site which was updated directly from 5.4.1.1 to 5.4.2.1 experienced the missing extensions problem.

Hope that helps. Let me know if there's any other info you need.

I have three installs, all versions of 5.4.2.1, installed within a couple days of each other.
A - installed ~10/7 (working file uploads)
B - installed 10/9 (working file uploads)
C - installed 10/10 (not working file uploads - needed the allowed filetypes solution)

A,B,C are:
* On Same host (HostMonster).
* Both SimpleScripts one-click installs.

The two that worked were on an old, long existing site.
The one that didn't was on a new account, new site (non-profit website I am building).

Boy that was a pain in the butt to figure out - kinda difficult to find in the forum as well.
Glad I did. :)

Thanks for posting your info. We're still looking into what the problem could be-- as you can imagine, since it seems to affect certain installations using these one-click install services, it's a little more difficult to replicate.

Just a headsup this applied to an existing installation as well on Hostmonster so you may want to add Hostmonster to the list of hosting companies.

Now I need to close my other thread. :)

Thanks.

thank it works

Yes, worked for me, too. Thanks.

@MattWaters
I just ran into this an I have a hunch that there could be a couple of package installers that are oops-ing on changing the UPLOAD_FILE_EXTENSIONS_ALLOWED config setting and accidentally blanking it with a failed str_replace.

Very interesting! Thanks for taking the time to post. We haven't been able to replicate it ourselves yet but this might be a good lead.

It's possible the Config::get("UPLOAD_FILE_EXTENSIONS_ALLOWED") is returning '' but I'm not sure. I'll send him a pm about it.

Any news about this?

The jacks_html_video addon does this in the install() method of the package controller


But I think you guys typically get it straight from the constant

because it's set in /config/app.php with

So if UPLOAD_FILE_EXTENSIONS_ALLOWED has never been modified by the user it is not yet in the Config table of the database so the Config::get ends up returning nothing so that str_replace ends up returning nothing. Then nothing is actually now stored for UPLOAD_FILE_EXTENSIONS_ALLOWED in the Config table so subsequent

now return blank as well.

hopefully that makes some sense?

Ah! That's very interesting, actually. Totally probably missed this in PRB review. I wonder if this is a common add-on in this and other problem installs.

Possibly. The way he did it was probably how I would have too.

Which brings up a point. Considering how concrete5 builds its config constants would it be a bad idea to have Config::get return the defined constant if there is nothing in the Config table or the cache?

Yes!! This was the only thing that worked! Thank you!!

Hi folks,

We believe we've found the cause of this problem-- a couple of marketplace add-ons were inadvertently affecting the Allowed File Types list.

Please see my updated post above for more info.