Inline scripts & styles
ttodua opened this issue · comments
Please add an option, so we can set i.e.
$incline_scripts = true;
and PLA outputed <style>.....</style>
directly into html head without linking to <link src...
.
There are many scenarios where we need such functionality, and would be excellent.
In which scenario do you need such functionality?
url-rewriting, subdomain, nginx, etc... There are cases, when PLA is not executed from it's direct location, instead "included", so, the path will never be resolved with ?
GET parameters.
In our case, we had to make this PR which fixes the problem, moreover, doesn't have any drawback/conflict with existing code/version, and noone will be bothered.
How do you "include" it in a way that breaks GET-parameters to ressources but doesn't break links and forms within PLA, which also make use of GET-Parameters?
Yes, it might be rare occasions from customers, but in our cases, we have many occasions, as we use WordPress sites.
i.e. say one example, including this in wordpress. You can access WP page at any link, i.e.:
so, there, in "index.php" file require(...PLA..);
however, requesting:
https://example.com/any-page/?resources=blablabla
ends in WP Query conflicts with other things, as that "resources" query param is being used by other app.
moreover, i havent heard any answer if there are drawbacks if you implement that feature.
thanks
I still don't get it. You could just exclude PLA from URl rewriting of WordPress. Put something like this:
RewriteCond %{REQUEST_URI} !^/(phpLiteAdmin/.*)$
Before
RewriteRule . /index.php [L]
In your .htaccess
file.
No, that it totally different and not affect/solves the problem. You are referring to other problem, and I meant the other case, when including the file without any actual PLA path exposed in URL.
moreover, asking the same question 4-times (about having no drawback of implementing PR, and avoiding us having puzzles of htaccess or custom approaches) and not getting any feedback, I assume it is not going to be integrated.
ok good luck,tnx
One main goal of PLA is to keep it small. Thus, we can't include everything just because it does not break anything. We include stuff when it seems useful for many users. I am asking you four times because I want to understand whether your change could be useful for other users.
As I understood you, your problem was that some other app in which you include PLA conflicts with the "resources" parameter of PLA. I can understand your fix in this case. But that seems a very specific problem that is unlikely to affect other users. Genereally, PLA is not meant to be included into other scripts this way. It will most likely cause many different problems depending on the script you include it in.
ok, i understand, just, including PLA in any file (i.e. mysite.com/myfile.php
), drastically needs PLA to have embedded resources (otherwise calls are fallbacked to mysite.com/myfile.php?resource=...
)
Probably the changes I've submitted , didn't increase the code/size of PLA, just several lines in sum.
As there were someone (i.e. me) who had found some profitability with that modification, it means, there might be also someone who might include PLA, but if it's first time you hear of that, i cant say anything then, maybe it's me only who used this file in other file, instead of separately putting.