Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set up a default public folder on contao:install command #712

Closed
wants to merge 1 commit into from
Closed

Set up a default public folder on contao:install command #712

wants to merge 1 commit into from

Conversation

Toflar
Copy link
Member

@Toflar Toflar commented Feb 24, 2017

I think a lot of users forget that as of Contao 4, folders are protected by default.
And even if you know about it, I guess every project needs public files and I found myself creating the same file structure over and over again. I'm always using

  • files
    • public
    • protected

While people might not like the "protected" folder, I think it is a good idea to create a "public" folder by default when setting up Contao. It makes setup faster and gives the users a hint about having to explicitly make folders public automatically.

@aschempp
Copy link
Member

I would delete this folder on every installation. Why would I create just one public and one protected folder? I create folders for their content and usually publish them…

If so, I would prefer a solution that folders are public by default like in Contao 3 (when added through the backend).

@Toflar
Copy link
Member Author

Toflar commented Feb 24, 2017

No protected foder is created? Public folders are public recursively. So it makes a lot of sense to just put everything that should be public in one parent folder named public. It's very explicit and I consider this to be best practice.

@aschempp
Copy link
Member

I absolutely don't. I use folders like files/layout/…, files/header-images/, files/foobar. Why would I want them to be grouped in a public folder?

@Toflar
Copy link
Member Author

Toflar commented Feb 24, 2017

The point is that you need to provide the users with some folders and I think it makes sense to add a public folder for them so they know exactly whatever is in this public folder, is going to be publicly available.

If you like to add a layout on the topmost level and make this public too, you can.

Anyway, I consider this to be best practice and I think it serves as a hint for administrators to see immediately that they have to make folders publicly available explicitly. That's why I want this to be part of the core. Let's see what others say.

@asaage
Copy link

asaage commented Feb 24, 2017

I am using a folder for each website-root as the first-level under files so i would probably delete public and protected after install.

Why not put a readme.txt file into files?
and maybe change the harddisk-icon to something that indicates that protected is the default...
image

Sometimes the recursiveness bothers me but that was the case in contao 3 too where you could not place a public-folder inside a protected-folder.

@ausi
Copy link
Member

ausi commented Feb 25, 2017

I found myself forgetting about the “protected by default” too, so +1 for the public folder. And for users that don’t want it, deleting a folder isn’t that much overhead I think.

@fritzmg
Copy link
Contributor

fritzmg commented Feb 26, 2017

Personally I wouldn't want to use it this way, since it creates an additional level in the URL for any public files (in additional subfolders).

Also just adding a public folder won't be enough I think. Users will just see that folder but not realize its significance, since there is no other folder to compare it to. If you had a protected folder as well, you would see the difference more clearly, since the protected folder will have an icon and the public folder will not.

Still, even then users just might assume it's the protected folder that has a special setting, not the public one.

Generally I never liked that approach in Contao 4 all that much, since you can't simply have public files in the /files directory now. They must be in a subfolder to be accessible publicly. But that's besides the point ;)

@aschempp
Copy link
Member

aschempp commented Feb 26, 2017 via email

@fritzmg
Copy link
Contributor

fritzmg commented Feb 26, 2017

Yes, the checkbox is definitely there when creating a folder.

@leofeyer
Copy link
Member

leofeyer commented Mar 14, 2017

I would delete this folder on every installation.

Me too.

Can't we solve most of the issues if folders are just public by default?

Yes, we could enable the checkbox by default.

I don't know if we should though?

@leofeyer leofeyer added this to the 4.4.0 milestone Mar 14, 2017
@leofeyer leofeyer removed this from the 4.4.0 milestone Mar 16, 2017
@leofeyer
Copy link
Member

leofeyer commented Mar 23, 2017

As discussed in Mumble on March 23rd, the "Public" checkbox should be checked by default. Also, it should be disabled in the subfolders of a public folder.

@leofeyer leofeyer added this to the 4.4.0 milestone Mar 23, 2017
@asaage
Copy link

asaage commented Mar 23, 2017

Instead of checking and disabling the "Public" checkbox in the subfolders of a public folder can't we introduce something without that strict recursiveness?

@ausi
Copy link
Member

ausi commented Mar 23, 2017

@asaage I don’t think that’s possible, because if a folder gets symlinked all subfolders are automatically public too.

@leofeyer
Copy link
Member

Implemented in b2b5a18.

@leofeyer leofeyer closed this Apr 28, 2017
@Toflar Toflar deleted the default-folders branch March 26, 2018 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants