<?php
$arr = array('a','ab','cd',array('ef','ad',array('cd','ae')));
$arrayIterator = new RecursiveArrayIterator($arr);
$it = new RecursiveRegexIterator($arrayIterator,'/^a\w*/',RecursiveRegexIterator::MATCH);
$recursiveIterator = new RecursiveIteratorIterator($it,RecursiveIteratorIterator::LEAVES_ONLY);
print_r(iterator_to_array($recursiveIterator,false));
?>
i want to get all strings which beginning with the letter 'a',
but it can not match the strings in 2D,3D...
Your code seems to be affected by a SPL bug (https://bugs.php.net/bug.php?id=68128) that is solved in PHP 5.5.19.
Take a look at the example at: https://3v4l.org/6H2oI
Your best bet is to upgrade your PHP version to the latest php 5.5 version (note that this version is not supported anymore and upgrade to php 5.6 is recommended)
Related
I have a fresh Mediawiki installed into fresh UBUNTU 18 LTS... The ''SyntaxHighlight'' extension not works for Unix shell, lang="sh", lang="shell", lang="bash", ... no one is working. It is not at #Supported_languages, and there are no clues about how to install "Other markup".
At mediawiki.org/list there are no clues.
So, how to solve the problem? It is a config, env or syntax problem?
NOTES AND TESTS
Notes.
It is a corporative Wiki, no way to offer public URL... But it is a fresh, standard and controlled installation, all reproductive and standard.
The Wiki was configured with skin "Vector" and language "Brazilian Portuguese".
Tests.
Usage tests of mediawiki.org/Extension:SyntaxHighlight, the Python example.
1.1. With tag <syntaxhighlight>. Result: no highlight, same as <pre>.
1.2. With tag <source>. Result: no highlight, same as <pre>.
PHP example, fragment from wikipedia.org/PHP Syntax.
2.1. With tag <syntaxhighlight>. Result: no highlight, same as <pre>.
2.2. With tag <source>. Result: no highlight, same as <pre>.
The code fragments used in the tests:
def quickSort(arr):
less = []
pivotList = []
more = []
if len(arr) <= 1:
return arr
else:
pass
<title>PHP "Hello, World!" program</title>
<?php echo '<p>Hello World</p>'; ?>
MediaWiki Syntax highlighter used Pygments library, you should first download and install the extension:
Requirements
This version of the extension has been tested with Pygments 1.6, 2.0.2 and
MediaWiki 1.25 as of 2015-06-19. To get releases of this extension compatible
with earlier versions of MediaWiki, visit:
https://www.mediawiki.org/wiki/Special:ExtensionDistributor/SyntaxHighlight_GeSHi
Download
https://github.com/wikimedia/mediawiki-extensions-SyntaxHighlight_GeSHi/archive/master.tar.gz
Installation
Add this line to your LocalSettings.php:
wfLoadExtension( 'SyntaxHighlight_GeSHi' );
By default, this extension will use a bundled copy of Pygments 2.0.2. If you
would like to use a different copy of the library, you can set
$wgPygmentizePath to point to the path to the 'pygmentize' binary.
Usage
On the wiki page, you can now use "source" elements:
<source lang="php">
<?php
v = "string"; // sample initialization
?>
html text
<?php
echo v; // end of php code
?>
</source>
Parameters
For details information of these parameters, see the documentation of Pygments'
HtmlFormatter at http://pygments.org/docs/formatters/#HtmlFormatter.
lang; Defines the language.
line; Corresponds to linenos="inline" option.
start; Corresponds to linenostart opion.
enclose; If set to "none", corresponds to the nowrap=1 option.
inline; Corresponds to the nowrap=1 option.
highlight; Corresponds to hl_lines option (comma separated).
Note
Pygments is generous about creating HTML elements: highlighting large blocks of
code can easily generate enough of them to crash a browser. As a guard, syntax
highlighting is turned off for code fragments larger than 100 kB.
Hello Im working with Image Intervention. Project working very well from local server.
My remote server Digitalocean droplet and Lamp Ubuntu 14.04 installed. Im sure all necessary modules installed and active.
GD Version => 2.1.1-dev
imagick module version => 3.1.2
PHP Version 5.5.9-1ubuntu4.21
Image::make('uploads/products/'.$filename)->fit(440, 585)->insert('uploads/watermark.png','center',0,0)->save('uploads/products/'.$filename, 100);
if ->insert function bypass my codes working on droplet. but when add to ->insert to code throwing error message.
Laravel 5.2 throw this error message: Command (insert) is not available for driver (Gd) Im trying all of my mind. how to fix this problem. I lost a one day :(
setlocale(LC_ALL, 'en_GB.UTF-8');
$file = $request->file('file');
list($filename, $extension) = explode(".", $file->getClientOriginalName());
$filename = strtolower(str_slug(uniqid().'-'.$filename).'.'.$extension);
$fileSave = $file->move('uploads/post',$filename);
Image::make('uploads/post/'.$filename)->fit(440, 585)->insert('uploads/watermark.png','center',0,0)->save('uploads/post/'.$filename, 60);
setlocale(LC_ALL, 'tr_TR.UTF-8');
I solved my problem.
I before using Turkish locale settings on server. When I set to Turkish locale settings on any Ubuntu version. All small "i" characters changing big "İ" characters. you know right classnames on Laravel Framework. Every class names starting big characters. We dont need "İ" character working with developing codes.
This problem stole 3 days from my life. I am 12 times rebuilding to server. Im happy now !
I'm using the following to upload an image from post data. it works on my server using php version: 5.2.16
When I try running the exact same script on my local server using MAMp and PHP Version 5.2.17
the file is not created.
if (isset($HTTP_RAW_POST_DATA))
{
// Get the data
$imageData=$HTTP_RAW_POST_DATA;
// Remove the headers (data:,) part.
// A real application should use them according to needs such as to check image type
$filteredData=substr($imageData, strpos($imageData, ",")+1);
// Need to decode before saving since the data we received is already base64 encoded
$unencodedData=base64_decode($filteredData);
echo "unencodedData: ".$unencodedData;
$key = microtime();
$key = md5($key);
// Save file.
$fp = fopen( '../../../uploadedImages/original/' . $key . '.jpg', 'wb' );
fwrite( $fp, $unencodedData);
fclose( $fp );
}
it looks like the post data does exist if I look at it in firebug. Any ideas why this isn't working in mamp?
Some things to try:
Check to make sure you are getting the raw data when the script is running on MAMP
Check the permissions of the directory it is trying to write to and make sure you have write access to it and apache has write access to it.
I had issues running some php modules on MAMP so I switched to using versions I installed using MacPorts. It gave me more control of extra extension I wanted to install and I got the latest versions of apache, php, and the php extensions.
I use CodeIgniter 2.1 and my production server was updated to PHP 5.4.3-1, and the pages that uses phpactiverecord don´t show nothing and don't show any error.
In my test servers with 5.3.6 works fine.
I use the nightly build version of May 2012. I try with the older versions and stable version.
Php-activerecord don´t work fine with php 5.4.3?
EDIT: I found that my new server doesn´t have displays_errors = ON. After activate it, I see the error:
Fatal error: Class 'Category' not found in /srv/www/framework/application/controllers/categories.php on line 26
at line 26:
$data["categories"] = Category::findby($parent_id);
categories.php exists in /srv/www/framework/application/controllers/ and this works fine on PHP 5.3.6.
I need to call something more or call at a different way?
I found the solution.
This solution is for php-activerecord through the latest SPARKS version.
Debugging the autoload_function, I´ve seen that the model file was loaded with the first letter capitalized, only in PHP 5.4.3, not in 5.3.x, and the file wash´t loaded.
Find the ActiveRecord.php at
yourfolder/sparks/php-activerecord/0.0.0.2/vendor/php-activerecord
Search the function:
activerecord_autoload($class_name)
Line 49 change:
$file = $root.DS.$file_name;
for
$file = $root.DS.strtolower($file_name);
And now it works!
p.d. I have found another strange case with PHP 5.4.3 before solve this. The function parse_url() returns false if your database password has a '/' on the string. Because of this, php-activerecord could not connect to the database in the file yourfolder/sparks/php-activerecord/0.0.0.2/vendor/php-activerecord/lib/connection.php at function: file parse_connection_url().
On PHP 5.3 returns the correct array.
I've tried stensi but I see it has some mistakes and unexpected output as mentioned in the user guide.
For example, when trying to delete a record it gives this error:
$p=new Per();
$p->where('id',1)->get();
$p->delete();
with an error message of:
undefined index id
when
echo $p->UserName;
outputs:
mhmd
and WanWizard has also this error:
<h4>A PHP Error was encountered</h4>
<p>Severity: Warning</p>
<p>Message: array_key_exists() expects parameter 2 to be array, boolean given</p>
<p>Filename: libraries/datamapper.php</p>
<p>Line Number: 399</p>
How can I overcome these errors or what can I do to make it work properly?
I've changed the two lines of code at ../libraries/datamapper.php line 399 (WanWizard version):
$d = array($this->config->item('datamapper'));
DataMapper::$config = $d;
and the error message disappeared.
If anyone has tried DataMapper and has a better suggestion, please let us know.
just found out this error can occur if you autoload the datamapper config file
Stensi's original version hasn't been maintained since 2007, and only supports CI 1.4. Not really an option anymore these days. It was forked by Overzealous in 2008, and I took over maintenance of that fork in 2010.
I fixed this (in the CI spark version) by moving the config file from the sparks directory to the /application/config directory.
There's something strange happening in CI v2.1.4 where
$this->config->load('datamapper', TRUE, TRUE);
on line 391 of application/libraries/datamapper.php in Datamapper-ORM v1.8.2.1 isn't "namespacing" the config correctly. If you do
print_r ($this->config); die;
just after line 391, you'll see all of the config values are in the general CodeIgniter "namespace" inside the loaded config array. The least intrusive way to get around this is to manually namespace your application/config/datamapper.php file yourself, by changing all the references from
$config['prefix'] = '';
$config['join_prefix'] = '';
...
to
$config['datamapper']['prefix'] = '';
$config['datamapper']['join_prefix'] = '';
...
That's how I got around it. Though #Mhmdgomma's fix does work, I prefer not to hack the core of the system when there is a simpler solution available. Someone should probably get the maintainers to fix this, but I'm not sure where the issue lies. It looks more like it's a CI issue, rather than DM.