I tried to import data from XML file using the importDump utility...
root#aace30d9b5f3:/var/www/html/mediawiki-1.36.1# php ./maintenance/importDump.php mrwiki-latest-pages-articles-multistream.xml
Got this error:
MWException from line 2108 of /var/www/html/mediawiki-1.36.1/includes/parser/Parser.php: PCRE needs to be compiled with --enable-unicode-properties in order for MediaWiki to function
I downloaded the source code of PCRE and run make / make install but that did not work. I am using the official docker image of mediawiki if that matters.
https://hub.docker.com/_/mediawiki
update:
I need to simplify what I am trying to ask...
Is PCRE compiled using --enable-unicode-properties in this dockerfile?
https://github.com/docker-library/php/edit/master/7.3/buster/apache/Dockerfile
Is that php image being used by mediawiki official repo?
https://github.com/wikimedia/mediawiki-docker/blob/51105612d2e1168f1b0545f47951847d63fb9613/1.36/apache/Dockerfile
PHP, unfortunately, usually uses its own PCRE library (from the manual: "By default, this extension is compiled using the bundled PCRE library"), as you can also see in this other answer.
What you need to do is recompile PHP itself in order to activate the PCRE changes. To do this you need to (you can do this on a cloned machine)
check out the exact PHP version
download and install the relevant source packages
get the exact compilation options from phpinfo()
change the PCRE options appropriately
make (you don't need install as you're not going use PHP in the cloned machine)
The only file that you need to change now is the basic PHP binary (/usr/bin/php, watch out for alternatives symlinks). If you used a cloned machine with the same distro and versions, you can easily rename that one binary on the original machine and move in the new one, and it will work (I've done this dozens of times), so you'll have the option to go back at any time.
Or you can install the development packages for PCRE on the cloned machine and supply --with-pcre-regex= and --with-pcre-dir= to the compiler. The new PHP binary will now use the system PCRE, so that pcretest -C will now yield reliable results. I am not sure whether you need the same PCRE version on both machines (you probably need the same major version, but a minor version mismatch shouldn't be a showstopper). Be aware that updating the system PCRE library might break compatibility with PHP if for any reasons the library calls change.
Related
Using Homestead, I try to run the BIGINT example #5 from the PHP docs and I get an "Integer overflow notice". The flag JSON_BIGINT_AS_STRING is ignored, and the result is invalid (a maximum bigint of 9223372036854775807).
The Homestead instance has the following software stack:
PHP 5.6.9
JSON 1.3.6 with JSON-C headers and lib 0.11.99.
I then tested it on 3v4l, and it works. I don't know their JSON setup.
I then tested it on OS X's pre-installed PHP which is:
PHP 5.5
JSON 1.2.1 and no JSON-C headers/lib.
This works, too - just like in the docs.
Subsequently, I found this issue which leads to this commit and seems to be what's causing the problems here, but why does Remi invalidate >64bit numbers and call integer overflow, despite the default JSON extension (present on 3v4l and OS X natively) not doing that? Doesn't this violate the claim that it's a "drop in replacement"? In its current state, this extension, which is included by default in many installations, goes directly against PHP's official documentation.
Are there any good solutions for this that don't require internal alteration of libraries used, like Guzzle?
Edit: Upon searching further, I have found this which confirms that one developer's opinion is the cause of problems here.
Yes, it's really just Remis opinion here. That way it clearly is not a 100% drop-in replacement. You ask why it's allowed? Because nobody can disallow a free developer to write his own code the way he wants.
So… all you can do is complaining and compiling ext/json yourself (instead of using JSON-C).
That means cloning from php-src source (https://github.com/php/php-src), checkout PHP-5.6 branch, navigate into ext/json directory and compile via phpize && ./configure && make install. Then add that extension to your php.ini instead of the json-c extension. [If necessary, you may need to first install some compiling tools...]
Note that with PHP 7.0 the json extension is replaced by a new implementation (see also the RFC: https://wiki.php.net/rfc/jsond), which doesn't have these issues and additionally has no license problems.
I have been struggling with installing the ImageMagick module to my XAMPP installation for my Typo3 application. The PHP is 5.4.19, x86, MSVC9. I have tried different versions of IM and IM module, always with different errors on Apache startup including
%1 is not a valid win32 application
php5.dll is missing
The procedure entry point MagickGetImageMatte could not be located in the dynamic CORE_RL_wan_.dll
The last of the errors was with the PHP 5.4 thread safe x86 module and the ImageMagick-6.8.8-7-Q16-x86-dll.exe ImageMagick installation. I then tried to copy the CORE dlls, which the module archive contained, into the ImageMagick folder (replacing the original ones). The error went away, the Apache starts without any errors, the imagick module finally appears in phpinfo, however it says
ImageMagick number of supported formats: 0
ImageMagick supported formats no value
and in Typo3 the associated functionalities suggest it still is not working properly. What can be done to make it work?
If I was you, I wouldn't try to use the ImageMagick PHP module any more.
This is not really necessary.
I am not even sure if TYPO3 can handle this module at all since I never tried it.
Since many years I just point the TYPO3 to the binary folder of ImageMagick where all the tools (convert, composite, identify) are located.
PHP must be able to call those binaries of course (exec() function must be anabled and this folder must be within open_basedir if used). It works this way since ever :-)
I recall the very few times I used WAMP environment I had no issues with it either.
Simply download the windows binary of ImageMagick and install it.
Inside the installation folder must be a folder called /bin.
The tools needed must be there as exec-files.
Now just set the TYPO3 configuration to point to this folder including the trailing slash.
For windows it must be something like this as I recall.
$TYPO3_CONF_VARS['GFX']['im_path'] = 'C:\\programs\\imagemagick\\bin\\';
You can use the binaries of GraphicsMagic instead of ImageMagick as well.
They are easier to find and perform very well.
I am trying to install the following php extension. Microsoft Drivers for SQL Server for PHP.
I have tried both versions of the driver but both seem to mismatch the version of php i am running. I looked around and it appears I have to recompile the modules in order to match the php api version. But I don't have any idea how to do this.
Any ideas on how to make this work? Or maybe a simpler way to use PHP 5.4.7 to access SQL.
You can do it with some tricks, its not recommended but it will work fine and in my case, it has not crashed yet :)
Check your phpinfo() page for:
1-PHP extension API Number
2-Thread safe or non-thread safe version
3-(Windows) compiler version
1-For building your extension you need php.lib. It is in your PHP-server dev directory.
2-You need PHP header files for compiling your extension, after including PHP header files, go to PHP/Zend directory and open zend_modules.h file and change the #define ZEND_MODULE_API_NO 20060613to your PHP extension API number for example change it to #define ZEND_MODULE_API_NO 20090626.
3- If you use windows based servers the compiler version is important(VC8 - VC10), if your PHP was compiled with VC8, build the extension in VS2008 or use VC8 for building your project.
If you encounter any wired error just comment it. I spent 3 months to make this worked ;)
I have an inconsistency, and I could not align their versions properly, so I just wanted to remove the library version. Can I do this? Is the header version for PHP while the library is from my distro? Can I upgrade PHP's library version? If so, how? I am using PHP 5.4.4
For example,
Is the header version for PHP while the library is from my distro?
It means it was compiled against the 1.0.1 headers, but is now dynamically linking against 0.9.8. So you are using an older version than what was used when PHP was compiled.
Many libraries store the version in the header files. So when a program uses the library, it can do something like int HEADER_FOO_VERSION = LIBRARY_VERSION, which embeds that version number into the program (e.g., php). Now when that program runs, it links dynamically against the library, which may be a different one than was on the host system.
That library may have a function call, say int get_library_version(). So the program (PHP) can check if HEADER_FOO_VERSION == get_library_version(). If it's different, then there could be a compatibility issue. (Of course, it doesn't have to be assign to a local variable... I'm just trying to drive home the point that the header version number can be compiled into php, and remains constant no matter which version of the library is being used at run time.)
Whether or not it is a problem depends on if the two versions are compatible.
Usually if the library is > than the header, you are okay. It's definitely more likely to be a problem if the library is older than the version it was linked against. Of course, this is because it's impossible to know what changes future versions may have.
So in your case, I would try to update your system's SSL libraries via apt-get, yum, etc, to match the version PHP is expecting.
To check which version php is using on Linux:
$ ldd `which php` | grep ssl
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0
Note that which php is just a short-cut to find the full path. You can hard code any executable you'd like to check: ldd /usr/sbin/httpd.
I dont know the answer myself, but when searched on google some nice resources explaining the same.....
What's the difference between a header file and a library?
The version of the files are the one mentioned in the phpinfo used to create a library.
Hope it helps, there are lot of resource available if searched on google.
Still will like to hear from someone in great details about the question
The header version is the functionality version, whereas the library version is the code version.
The header defines the interface - it tells you what functions are within the library. If a header gets updated, then you need to check to make sure all the functions are the same, and see if any are added or subtracted.
But if a library gets updated, and not the header, it means all the function calls are the same, but some of the code may be changed (eg, bug fixes).
In your example, PHP is seeing functionality for OpenSSL 1.0.1, but the actual version of the source code that OpenSSL is loading is 0.9.8o
This is commonly seen on updated versions of openssl. What happens is the newer versions for the libraries are stored in different folder. The original folder located at /usr/bin/openssl would need a symbolic link to the new folder /usr/local/bin/openssl. That would get both to be the same version or just show OpenSSL Version _(Whatever)
Normally there is no concern for this, since it still works the way it is intended. This is seen a lot on shared servers.
EDIT:
The information in this post is generic and can be different if you are running
CentOS, RedHat, Ubuntu, or another Linux/BSD version. Check documentation or man
pages for the best information
If you do update your OpenSSL, some versions of *nix Require for you to rebuild PHP and Apache for it to update
If you are rebuilding PHP from source, I have found another possible reason for a mismatch. It's so simple yet if you are not familiar with building from source on Linux, not knowing it can cost you a lot of time.
The answer is here: https://serverfault.com/a/567705/305059 - unfortunately I cannot up-vote it over the not-so-useful answer, so if you have the reputation there, please do.
You need to run "make clean" before "make" in order for it to rebuild all binaries. Strangely, without this step I was getting an updated library version, but the old header version - so I think it must have rebuilt something, but not everything. My rebuild involved linking to a version of curl in another location (built with ssl), which might be the reason behind it.
Anyway, I hope this helps someone. Thank you to #velcrow on serverfault.
I don't do a huge amount of php work and I've never used bcompiler before but I'm migrating a php site to a new server and I can't get this working.
There seems to be a class compiled with bcompiler 'class.viewimage.php' - it contains bz compressed code 'BZh91AY&SY;iu...'
There is then a regular php file that is calling this class:
require('class.viewimage.php');
$my_image = NEW ViewImage ($MEDIALIB->Filestore);
When this code is run it just spits the text contents of the compiled class into the browser ('BZh91AY&SY;iu...'). It's the require line which is causing this. Seems to me like php doesn't magically know that this is compiled code.
To the best of my knowledge I've installed Bcompiler on the system as this code is no longer crashing (and it was crashing when I first did the migration):
if (!extension_loaded('bcompiler')) {
$prefix = (PHP_SHLIB_SUFFIX === 'dll') ? 'php_' : '';
dl($prefix . 'bcompiler.' . PHP_SHLIB_SUFFIX);
}
Any help appreciated.
While I've had my own troubles with PHP bcompiler, using include() or require() to access compiled code (compiled using bcompiler_write_file()) on a machine with the bcompiler module installed and enabled should work.
http://us2.php.net/manual/en/function.bcompiler-read.php:
Note:
Please use include or require
statements to parse bytecodes, it's
more portable and convenient way than
using this function.
Not only are there a multitude of bugs, but versions are incompatible with one another, which is what I'm guessing is your problem.
For example, my two (incompatible) machines:
CentOS 5.5, PHP 5.2.10, Apache 2.2.3, x86_64
----
bcompiler version 0.9.3-devs
current bytecode version 0.21
can parse bytecode version 0.7, 0.9, 0.11, 0.12, 0.14,
0.18, 0.21
Mac OS X 10.6, PHP 5.3.3, Apache 2.2.15, i386
----
bcompiler version 0.9.3-devs
current bytecode version 0.22
can parse bytecode version 0.20, 0.22
I submitted it as a bug to the PECL package.
PHP considers all require/include files to be plain text, and will treat them as such until it spots either the <? (shorttag), <?php (regular tag), or <% (ASP tag) character sequences in the stream, after which it switches into PHP mode, until it hits the end of the script or the corresponding closing tag (?>, %>). As such, there's no way to have PHP treat a compiled input as program code. Even an EVAL won't help, since that just invokes the same parser that didn't trigger off the binary input in the first place.
BZipped code itself isn't executable either, unless it's been wrapped by an auto-extractor stub.
Since it would appear to be BZipped, why not try un-bzipping the file and see what you get? Maybe the class file was downloaded as a .bz2 distribution and simply got renamed. The uncompressed copy may contain the appropriate wrappers to allow execution.
I have been struggling since a long time to work with bcompiler but surprisingly i found a very easy solution where you can compile you whole website with one click. you can follow the bellow steps:-
Download and install Wampserver (any edition).
Download and install Wampserver PHP Addons Version php 5.2.5
click on Wampserver -> PHP -> Version -> 5.2.5 from Task bar (it will change your current version of php to 5.2.5).
Select Wampserver -> PHP -> extension -> php_bcompiler (it will enable bcompiler on your computer).
Above steps are enough if you can compiler the script your own but to make it easy you can continue with next steps.
Download bcompiler GUI.
Select the Folder on the Bcompiler GUI and this will compiler your whole website with one click.
enjoy PHP | Enjoy Open Source