# PATCH Deprecated modules patch. - Thread: https://externals.io/message/1018 - Original archive: https://news-web.php.net/php.internals/1018 - Started by Michael Loftis on 2003-04-23T19:13:27+00:00 - Messages: 2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #1018 — Michael Loftis — 2003-04-23T19:13:27+00:00 URL: https://externals.io/message/1018#1018 I've done a small patch (no ./configure option at this time) that allows you short-circuit loading of modules. mw_deprecated_extensions is the new config variable, set as a PHP_INI_SYSTEM restriction level. It has a little bit of OS specific code, only tested on Linux, should work on any Unix though. Not tested under Win32 and probably won't work there. In order to get it to work at this point you need to #define MW_DEPRECATED_EXTENSION I don't know that this is the best way to do this but it seems that if the team wants to keep moving modules into the core we need to make a method for large web hosts (like my employer Modwest here) to be able to make a list of modules to not try to load so as to make moving between versions somewhat more transparent. The patch against 4.3.1 is attached, I welcome any comments or suggestions for improvement. I do fully agree with Sascha that what is *really* needed is something else entirely, but this is a stop-gap measure that we're going to use in the meantime. Extensions should be able to inform of their status at any given time. This is a hack but until such time that a better method is employed it would be nice to have something like this. I'll be making further changes so that PHP loads an extra INI file specifically just so we can put the mw_deprecated_extensions directive in a file by itself and thus not have to touch everyone's INI files here. For us though compiling more and more into the core statically poses a performance and scaling problem. If we can save startup time we always do, which is part of the reason we use dynamic extensions, instead of compiling in everything anyone would/might want we make them as modules. -- Michael Loftis Modwest Sr. Systems Administrator Powerful, Affordable Web Hosting --- ## #1038 — Jani Taskinen — 2003-04-25T08:50:21+00:00 URL: https://externals.io/message/1018#1038 · In reply to: #1018 You should always use '--disable-all' as first option and then enable what you need. No idea what your patch was about but it propably was useless anyway. --Jani >I've done a small patch (no ./configure option at this time) that allows >you short-circuit loading of modules. mw_deprecated_extensions is the new >config variable, set as a PHP_INI_SYSTEM restriction level. It has a >little bit of OS specific code, only tested on Linux, should work on any >Unix though. Not tested under Win32 and probably won't work there. > >In order to get it to work at this point you need to #define >MW_DEPRECATED_EXTENSION > >I don't know that this is the best way to do this but it seems that if the >team wants to keep moving modules into the core we need to make a method >for large web hosts (like my employer Modwest here) to be able to make a >list of modules to not try to load so as to make moving between versions >somewhat more transparent. > >The patch against 4.3.1 is attached, I welcome any comments or suggestions >for improvement. > >I do fully agree with Sascha that what is *really* needed is something else >entirely, but this is a stop-gap measure that we're going to use in the >meantime. Extensions should be able to inform of their status at any given >time. > >This is a hack but until such time that a better method is employed it >would be nice to have something like this. I'll be making further changes >so that PHP loads an extra INI file specifically just so we can put the >mw_deprecated_extensions directive in a file by itself and thus not have to >touch everyone's INI files here. > >For us though compiling more and more into the core statically poses a >performance and scaling problem. If we can save startup time we always do, >which is part of the reason we use dynamic extensions, instead of compiling >in everything anyone would/might want we make them as modules. > >-- >Michael Loftis >Modwest Sr. Systems Administrator >Powerful, Affordable Web Hosting > -- <- For Sale!