phpLiteAdmin / pla

Official github clone of the phpLiteAdmin repository
https://www.phpliteadmin.org/
173 stars 36 forks source link

Inline scripts & styles #24

Open ttodua opened 3 years ago

ttodua commented 3 years ago

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.

crazy4chrissi commented 3 years ago

In which scenario do you need such functionality?

ttodua commented 3 years ago

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.

crazy4chrissi commented 3 years ago

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?

ttodua commented 3 years ago

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.:

https://example.com/any-page/

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

crazy4chrissi commented 3 years ago

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.

ttodua commented 3 years ago

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

crazy4chrissi commented 3 years ago

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.

ttodua commented 3 years ago

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.