-
Notifications
You must be signed in to change notification settings - Fork 37
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
Reword the Resource access restrictions
chapter
#165
base: develop
Are you sure you want to change the base?
Reword the Resource access restrictions
chapter
#165
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
English review OK.
Completely disagree with the described functionality.
PHP files shouldn't be in the public directory at all and I see no good reason to support ".js.php" types of assets.
This is only to support legacy scripts. There is a lot of plugins that have PHP files outside their
I agree that having JS files rendered by PHP is not really a good practice, but I think trying to filter resources depending on their type is not our job. As long a a plugin developer puts a resource in the Anyway, I will change the name of the resource to |
06859eb
to
095a9d2
Compare
Masbe should we just inform users that it's not a god practice? For now, the main problem is we do not have any existing alternative to propose. |
We have to write a documentation about how to create a plugin Symfony controller to be able to add a note indicating that legacy scripts should be refactored. I guess both should be done in separate PRs, but we can keep the current PR in draft mode for the moment. |
If this is only for scripts that were in the root of a plugin folder and nothing else like the inc and src folders, then I think I misunderstood and it needs clarified in the documentation. |
No description provided.