I think we can add Upload Limit hint at extension manager

[asika32764]

Since PHP default upload size is set to 2M, many of my friends (Not developers) complain about not able to uplaod extension files. It is hard to check file size when uploading, we can add an information to notice user about the upload limit like: "Upload max size: 2M".

Just provide an idea and discussion, I'll do this stuff if I have time.

[Bakual]

Make sure you don't miss the PR #4348 which would help with that.

[asika32764]

Thank you. It's seems a good help.

[dgrammatiko]

@asika32764 Maybe a call to the new function will provide site wide this info? I am thinking some some code here https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/form/fields/file.php#L129 formatted as label...

[asika32764]

@dgt41 This idea is not bad. But I need more opinion about how to customize the label of file field? Maybe some developer do not love to use default style and want to use custom template to show the notice. Maybe it is a good idea that move html to JLayout?

[dgrammatiko]

@asika32764 Yes we have JLayouts so if we use that everybody will be happy! I will suggest to put an option like $limitinfo or something and if is true the label will render otherwise only the button will be displayed. That’s also the best way to implement it without breaking B/C or every templates.

[beat]

You can use some of the strings that I have updated in merged PR #4210 following @nikosdion 's merged PR #4209 .

It would be great to show a message like:

Maximum File Size: 2M (upload_max_filesize in /etc/php5/cgi/php.ini)

on the right or below all file-upload fields in the admin area (that's what I do in CB 1.9.1).

That indication is helpful to the user, as it not only shows the limit to the user, but also in which file they can set it, as you know which setting is limiting it (thus you need to know which setting is the limiting factor, maybe generating that text is something to add at library level, maybe even in PR #4348 ), and from where. https://stackoverflow.com/questions/13076480/php-get-actual-maximum-upload-size/25370978 might help too in locating origin if needed.

[brianteeman]

I really disagree with that. Its not a helpful message as the user on most
shared hosts would not be able to access that file and the recommended way
for them to adjust it on their hosts may be to create a local php.ini file.

You are just adding a technical geeky string which doesnt mean anything to
most users and provides incorrect advice for many users

On 26 September 2014 14:46, beat notifications@github.com wrote:

You can use some of the strings that I have updated in merged PR #4210
#4210 following @nikosdion
https://github.com/nikosdion 's merged PR #4209
#4209 .

It would be great to show a message like:

Maximum File Size: 2M (upload_max_filesize in /etc/php5/cgi/php.ini)

on the right or below all file-upload fields in the admin area (that's
what I do in CB 1.9.1).

That indication is helpful to the user, as it not only shows the limit to
the user, but also in which file they can set it, as you know which setting
is limiting it (thus you need to know which setting is the limiting factor,
maybe generating that text is something to add at library level, maybe even
in PR #4348 #4348 ), and from
where.
https://stackoverflow.com/questions/13076480/php-get-actual-maximum-upload-size/25370978
might help too in locating origin if needed.

—
Reply to this email directly or view it on GitHub
#4355 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

[nikosdion]

I agree with the concept, not the implementation suggestion. It would be better to add that to the description string in the Warnings. We should tell the users something like "Ask your host to fix this. If you are self-hosted, e.g. on a local server, edit your php.ini and change this and that to such and such". Or at least link the message to a page where we explain them in detail what to do. If you want the lengthy text that 100% of my clients were able to follow it's in https://www.akeebabackup.com/documentation/troubleshooter/abinstallation.html under "You get an error about the package not being uploaded to the server".

[dgrammatiko]

@beat @brianteeman I also agree with Brian here. I don’t see the use to inform every end user about technical stuff. Maybe we can add one more line @ system information tab for max upload limit and there point to php.ini

[beat]

@nikosdion I agree with your suggestion to make the string more average-user-friendly, and still think it helps to know which is the limiting setting, since there are 2 settings max upload and max post sizes that. Nice long text btw.

@brianteeman only partly agree with you, and that's ok. Even for the average-hoster (lol), that indication can be useful.

[asika32764]

I think we can implement this in 2 ways, one is show a message about upload limit, the other is show a link to "System Information" page or Help Center on docs.joomla.org when uploading failure.

[dgrammatiko]

@asika32764 It will be nice if there is another (?) option to choose between just the max value and the more informative msg

[asika32764]

@dgt41 Yes, maybe. I'll try which is better and easy to understand when I'm implementing this function(but not very fast). Or everyone can to do this stuff before me and provide us some opinion.

[roland-d]

I agree with @brianteeman statement, that this is a geek thing with which most users wouldn't help. However I do think it can be useful in case of troubleshooting. How about showing this info only when the debug mode is on, like we have with the ACL permission report?

[dgrammatiko]

@roland-d but will you ever enable debug on a live site?

[roland-d]

@dgt41 the same can be asked why the permission report only shows when Debug is on. With any kind of problem you would test it on a test site not a live site.

[dgrammatiko]

@roland-d Maybe if we set it to show only on back end a more informative message is better?

[roland-d]

@dgt41 In general I think the debug info should only be shown to super admins, regular users have no business debugging the system :)

[brianteeman]

@roland-d that is already in the plugin

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

[roland-d]

Thanks @brianteeman for the info. So yeah, I still stand by that we can the show it only when debug is on. This information you don't need all the time either, so no need to fill up screen space with it when not needed.

[dgrammatiko]

My final thought on this one: I suggest the simplest approach here, just echo the max file size, but I would also like to propose two more changes that are related to this. A message on post-install of Joomla and the same info in admin system info, where optimal values for PHP (regarding max file upload size and max post size) are given and also the paths where the .ini files exist, as @beat proposed.

[brianteeman]

I repeat what I said before - stating the paths of the .ini files is
useless for 99% of users on shared hosting

On 27 September 2014 12:08, Dimitri Grammatiko notifications@github.com
wrote:

My final thought on this one: I suggest the simplest approach here, just
echo the max file size, but I would also like to propose two more changes
that are related to this. A message on post-install of Joomla and the same
info in admin system info, where optimal settings for PHP are given and
also the paths where the .ini files exist, as @beat
https://github.com/beat proposed.

—
Reply to this email directly or view it on GitHub
#4355 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

[VNiemi]

Since PHP 5.3 is required for Joomla! 3, would there be an issue notifying user about the problematic directives and suggesting fixing it in the correct place:

.user.ini if cgi/fcgi
.htaccess if apache mod

Checking which case applies is relatively simple. In any case, "no access to php.ini" is not really relevant for PHP_INI_PERDIR directives with Joomla! 3 due to increased PHP version requirement. Some servers do block these, but that is an issue with server configuration, not really an issue for Joomla!

Same would apply to some other directives, such as output_buffering, max_execution_time and memory_limit, which relatively often cause issues with installs and updates. Many Joomla updates and installs fail on timeout and running to memory_limit after update is a thing that happens. And some extensions are (or atleast were) incompatible with output_buffering.

Actually it might be worthwhile to include a default .user.ini with compatible values in the same manner a htaccess.txt file is provided and suggest using it, if known to be problematic values are detected with cgi/fcgi. Maybe a .user.ini tool for modifying some of the settings where the correct value may vary. Some sites need higher upload sizes than others.

[nikosdion]

The actual file which needs editing depends on the host's implementation of PHP. Usually it's the php.ini in the same directory as the respective index.php or the .htaccess but in many cases you are either given a php.ini for your entire account or have to ask the host to edit their own php.ini. Or if you're using a local server (the most common case of a limited upload size, to be honest) you need to follow the instructions of your *AMP package. At best we can tell the user which directive needs editing. We can't tell them how to edit it.

Also, it's NOT a a good idea including a default php.ini file in Joomla! itself. If the host forbids overriding any or specific values then you'll end up with a blank page or a 500 Internal Server Error without any explanation as to what is going on. From the point of view of an inexperienced user –the same user you want to serve by adding this file– Joomla! is a stupid, broken thing that they'll never waste any time on ever again. Unfortunately that's how end users think. The more advanced users already know how to change php.ini directives or how to use Google to find out how to change php.ini directives.

[VNiemi]

Not "php.ini", ".user.ini". It allows PHP_INI_PERDIR directives to be set on a per directory basis since PHP 5.3.0. So with minimum requirement being either 5.3 or 5.3.10 and apache_mod servers becoming less common, it is usable enough to be worth talking IMHO.

[VNiemi]

And I did not suggest enabling the file by default, I agree that would be bad. I suggested having a sample file available and suggesting enabling it if it looks useful. So the user would reasonably be able to connect the error with the file being enabled. Also these particular directives are relatively rarely blocked, as they are relatively safe. That is why they are PHP_INI_PERDIR, after all.

But, yeah, some hosts do block stupid stuff... And that would probably be the same ones that have silly upload size restrictions.

[nikosdion]

Yes, they tend to be the same ones according to my experience. Based on the feedback I get from my clients the limited upload size tends to happen on local *AMP servers which seem to all be using the default max upload size of 2M and backwaters hosts who use the default 2M max upload size and silly restrictions. There are a few decent and semi-decent hosts who forgot to set a larger max upload size but will happily fix that when it's pointed out to them. I've not had feedback from any client telling me that the user-defined php.ini file was the solution to their problem.

[VNiemi]

I use Admin Tools and Backup and I have modified the WAMP php.ini (saves LOTS of trouble) and have used .user.ini files to up download sizes on servers. Does that count as feedback?
You are right that asking the host might have been a cleaner solution, though. But hosts with silly configurations also tend to be a pain to talk with. Just changing the setting is much faster.
Incidentally, are you sure that blocked directive in .user.ini can cause a blocking error? While that happens with .htaccess, I seem to vaguely recall PHP just ignoring directives it can't change.

[nikosdion]

Yep, you're the first one to tell me that has used a .user.ini on a live server. That most certainly counts as feedback.

Incidentally, are you sure that blocked directive in .user.ini can cause a blocking error?

To be perfectly honest, I don't think that sort of thing will cause an error. If the host is using the original PHP sources they can only disable .user.ini files completely by setting user_ini.filename="" in their server's php.ini. Then again, I've seen hosts installing all sorts of misguided patches against PHP...

As for .htaccess, yes, it will cause an error as long as AllowOverride Options is not granted. Exactly as you thought it would happen.

[VNiemi]

Really. It kind of makes sense since most people probably don't even know .user.ini is an option, but on the other hand issues caused by these settings being "wrong" are quite common. I am hardly what you'd call a pro and I have run into problems with every one I mentioned and a few others. Magic quotes can break JCE and short tags was needed for some legacy code on a site I moved, although that was just me being lazy and trying to avoid (and failing) having to edit the code. All fixed with .user.ini and few minutes mostly spent googling the correct way to write the directive name.

If .user.ini fails safely using it might be an option when obviously problematic settings are detected and server uses a compatible PHP interface. It is actually safer and simpler than telling users to rename htaccess.txt, if they want links without index.php. It might even be worthwhile to have an actual administrator UI for the upload sizes like using rewrite does.

Offtopic, but it might actually be useful if Joomla! (maybe extensions too) install and upgrade had an ability to use higher max_execution_time than normal thru .user.ini. Not only is that a common issue, but time outs don't really give any useful feedback, so a user might just give up.

[coolbung]

IMO - The only thing we need to show here is the upload limit and the file types allowed. That applies to any other upload fields too.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4355.

[jissues-bot]

Set to "closed" on behalf of @brianteeman by The JTracker Application at issues.joomla.org/joomla-cms/4355

[brianteeman]

Please see #4837 for a proposed solution