Just one more question before closing out this issue.
Here
techpatterns.com/forums/about2046.html&highlight=
you wrote

Drush is the Drupal shell, which simplifies lots of operation on this CMS and is in the Debian repo.
Drush complains about the disable_functions settings in php.ini because it is non-empty and drush throws error with that config.
I commented out that line and drush works clean.
Now, if that config is global it will affect all sites in my local server and I was wondering if I can set that version only for Drupal site with virtual hosting.
Back to top

Sounds like a good reason not to use drupal. I have no idea of anything related to drupal, or debian packages of drupal, all that stuff to me is just looking for trouble, so I never use that type of stuff. Cpanel is bad enough, and boy is it bad. And of course, stuff like all in one lamp packages are also bad, just more complexity added to what should be fairly basic configuration files. Drupal is a fine product for very complex large sites, but it's massive overkill for anything you'd be involved in. That's the thing that runs for example whitehouse.gov and other very large websites, that are very dynamic and have a lot of constantly changing features and content. I'd use drupal if I got paid to do it, but not under any other circumstance, their problems with major version upgrades failing makes it a very poor choice for realworld sites, unless you have a pretty major time/money involvement in the process, ie, you get paid to deal with the failures and problems.

I have always avoided this type of junk, because it just adds one more layer of complexity, makes debugging core issues harder, not easier, and I avoid packaged web software like drupal because you should never upgrade this stuff blindly, it should be under your control, those upgrades can and do fail, and if it's packaged, good luck ever getting support for the failure, who is at fault, the drupal devs will point to the debian dev, the debian maintainer will point to the drupal devs, and your site will be broken, with basically zero recourse for help at that stage.

My recent experience with cpanel's constant breaks and failures has proved to me that such tools are never a good idea, if you can't run the stuff, then use managed hosting, if you can, do it yourself. this is why I use pair networks, by the way, they run their own control panels, ACC, written by them, so it doesn't suck, which is highly unusual.

So no idea, in answer, I would never use the stuff you are using, though if I had to, I'd use drupal alone, but certainly not a debian packaged version of it, and most certainly no drupal shell type thing, that sounds like a total horror show. This kind of junk is why sites get hacked constantly, so many insecure layers added onto what is basically a very solid LAMP or BSDAMP stack, it grows almost trivial to find holes in at least one piece of the extra layers, especially when they aren't updated in a timely manner if common tools.
Back to top

Seems to me you got a tad bit overworked.
There are no Debian packages for Drupal, the only one is drush, which is a CLI to do things faster, and is not a part of Drupal.
I am not using any CPanel, I am talking about what happens in my local server, installed with smxi, so again, the question is:
Is there a way to direct drupalsite.conf (this is an example) in /etc/apache2/sites-available to use a custom php.ini, valid only for that site?
PS: Congrats on Magnus Carlsen for winning the chess world championship.
Back to top

no, you use apache php directives to do custom php stuff. php.net has great documention, it's a resource you should get familiar with, here's their list of apache php directives

Those directives go either in the htaccess of the site configuration in apache, the files you made in sites-available/ that is.

Pretty much all of them can be switched off on adjusted via apache configuration.

You know, at least hopefully, like:


that overrides the default include path set in php.ini, for example.

Sometimes it's hard to actually get what you are asking because the stuff is so basic that you should have already gotten past that point a long time ago so the question makes little sense to me in that context.

The reason I got worked up is you have a tendency to find ways to do things that make it much harder to offer help. I'll just ignore the drupal thing, though it's a very very very complex tool to use unless you are wanting to actually make money at it.
Back to top

Drupal is just an example of what I need to do, the answer to my question is not specifically related to it, so just forget Drupal, not good for your blood pressure.
I am aware of php_value include_path, it is in a previous thread, when I just started asking about virtual hosting.
There is something that is not clear to me:

Most CMS have their own custom .htaccess that ships with them, so add directives to that one?
Or insert php directives in the .conf sites in /etc/apache2/sites-available?
Back to top

if drupal is not related, then don't mention drupal as if it's part of your question. Except to note that you happen to be testing it.

If the question is not clear, how can it be answered?

The includes thing is an EXAMPLE of a php apache directive, I really don't know how to answer your questions sometimes. As an example, and with the links I provided, you should in theory now be able to figure out the answer to whatever the actual question you have is.

In general I will suggest this: stop avoiding learning core concepts before doing things, it's a bad idea, and it doesn't work well. Your questions here point to you simply not having learned how to use apache configurations at all, otherwise you would simply not be asking these questions.

Here's how I do it: on my local dev system, allow override is always set to no, ie, htaccess is inert, and does nothing. That lets me make htaccess files that work on the remote system without having to also try to make them work on the local system. Apache paths etc are always absolute, and related to the actual file system apache is running on.

So there's almost no case you'd want to use .htaccess on your local system because the paths are going to be different from the live site. So that means you use apache configuration files to set paths, directives, etc.

With this in mind, your question doesn't exist, since you'd always use that method on your local box. Now that we have step 1 settled, you can move to the actual question, whatever that is.

Let me reread your initial question, but in general, avoid posting onto a solved thread a new issue, post a new thread, that way it's clear what the actual question is. I've never understood why people are so reluctant to start new threads on forums.

So I'll split this thread and then see if I can figure out what your actual question is.

Now, go and reread your question, you'll note that almost the entire post is about drupal and drush, and only the last line mentions what I assume is the actual question. This is not how you post technical questions, ask the actual question, so that people reading it understand the fact that is your actual question, then add as examples etc why you are asking the question, making clear all along what the actual question is.
Back to top

Ok, I've reread your original question, and now believe your question is this:



In other words, the question IS ABOUT DRUSH, so we can't ignore it, that's the cause of the problem. How can you expect people to help you if you aren't even aware of the question?

So let's do a quick google search on your actual question:

google disable_functions php.ini

This gives as the first result:


So now we know something, drush is complaining because your php.ini file has a deprecated thing in it, actually removed, not deprecated.

so we read that php.net page, which is what you should always do FIRST, before asking anyone for help:


and there you have it, what may be the answer. Of course, in terms of php versions, I don't know, but this directive basically can be safely removed since it was certainly deprecated as of your base system's php, and is now removed.

Notice how I just did all your work for you, and that really, in the real world out here of computer work, you yourself should have googled the key words, read the php.net information, then if there still remained a question to be asked, you'd ask it. In this case, there is no question that I am aware of remaining.
Back to top

Thanks for detailed answer.
Let me explain a bit more.
I never did anything in the php.ini file, it is what Debian loaded in there, cannot figure out why if my PHP version is there is a function there that is deprecated since 5.4.0.
Anyway, before posting here I had already solved problem with help from Drupal IRC, simply commented out the line and my specific problem (drush) worked without complaining, not that it did not work before, I just wanted to get rid of the pesky error.
Now, I thought that there could be a better solution and that is leaving the line uncommented as it shipped from Debian, and doing something like:
in my virtual site example.conf
because the actual error I was getting was that disable_functions was not empty.
My intention was not to post a question on Drupal or drush, I am not that dumb, I know that would be off-topic, regardless of what your opinion of that CMS is, I am not going to debate that here.
It was just a question on how to configure php.ini for a specific site, and not globally.
Also, please understand that my personal obligations do not always allow for in-depth reading and I have to solve problems as I go because those are critical for my livelihood, also I am fairly new to this, so go easy on me, will ya?
I will post results of my testing here.
Back to top

in sites-available did not work, I had to comment out that line to make it work.
Back to top

quoting myself quoting the specs for this feature, and highlighting the relevant part, one notes that yes, in fact, this can only be set in php.ini, and, further, it must receive a list of functions to disable, so there you have it. What you did shouldn't have worked and it didn't, so Apache is fine.
Back to top