I'm a long time reader, but new to asking questions. Please correct me if I have somehow asked incorrectly.
Intro
We are upgrading our servers from PHP 5.4 to PHP 7.2 and one of the libraries that is not fully compatible with the new version of PHP is PHPExcel. So, we are upgrading to PHPSpreadsheet as well. A lot of our projects use PHPExcel in different ways, so if I can get the Auto Migrate tool to work, it would be a huge time save for me even if it misses some things.
The instructions to use the tool are found here:
https://phpspreadsheet.readthedocs.io/en/develop/topics/migration-from-PHPExcel/
And they simply say to use the following command after installing via Composer (which I've done):
cd /project/to/migrate/src
/project/to/migrate/vendor/phpoffice/phpspreadsheet/bin/migrate-from-phpexcel
Problem
I am able to execute the migrator fine, but it only scans files inside the "vendor/phpoffice/phpspreadsheet" directory. It does not scan any files inside my project at all.
How do I get the migration script to scan my projects files, and not it's own files?
Local Environment
Windows 10
Latest XAMPP
PHP 7.2.11
How I Am Running It
cd C:\path\to\project\that\uses\phpexcel
php vendor\phpoffice\phpspreadsheet\bin\migrate-from-phpexcel
How I have Tried To Solve So Far
Running the exact command on the instructions page (ends up running two commands, second one is an invalid command)
Moving "migrate-from-phpexcel" to my project root and running it there
Editing "migrate-from-phpexcel" after moving to project root and pointing to the Bootstrap.php file (Runs, but only inside the library itself. Same problem)
I don't know how, or from where, you ran the 2nd command but that command traversed my whole project and made what looks like appropriate conversions. I ran it from project root while I was IN my IDE (PhpStorm, using its 'Run Command' tool). I ran the same command you did, like this:
php vendor\phpoffice\phpspreadsheet\bin\migrate-from-phpexcel
After confirming "yes", I saw it traverse the directory, changing various files but skipping its OWN files.
When I tested my script, I encountered a warning about 'a non-numeric value' from one of its modules (Coordinate.php on line 312 & line 313). I did some research on the warning but couldn't find anything to address it except people blaming PHP 7.1** (I'm running 7.2.*). So I suppressed the warning and my spreadsheet was created exactly as I specified.
Here is my first statement in my 'create excel' script:
error_reporting(E_ALL & ~E_NOTICE & ~E_WARNING);
The only other "manual" change I had to make was changing the file format of the 'createWriter' from 'Excel2007' to 'Xlsx' -- exactly as it states in the docs. A more complicated spreadsheet may require more manual work, but probably not as much as someone above indicated.
In case it helps someone else: while updating a legacy project that was using PhpExcel v1.8.2, running rector on the codebase failed on most of the files that needed to be processed, with the error:
[ERROR] Could not process "test.php" file, due to:
"Analyze error: "PHPExcel_Writer_Exception (Unable to load PDF Rendering library) thrown while looking
for class PHPExcel_Writer_PDF_DomPDF.". Include your files in "$parameters->set(Option::AUTOLOAD_PATHS,
[...]);" in "rector.php" config.
See https://github.com/rectorphp/rector#configuration".
To get around this, I followed suggestions here: https://github.com/rectorphp/rector/issues/6418#issuecomment-882923495 and commented out lines in the PhpExcel install itself - the lines containing throw new PHPExcel_Writer_Exception('Unable to load PDF Rendering library'); in files DomPDF.php, mPDF.php, tcPDF.php in Classes/PHPExcel/Writer/PDF/
2022+ Automated Upgrade Approach
Discalimer: I wrote a tool that handles automated migration from CLI called Rector, so people don't have to upgrade PHP code manually anymore. It's free, open-source, on GitHub.
The offical migration tool only fixes class names. There are 24 more cases, that needs to be changed, lLike mentioned "'Excel2007' to 'Xlsx'".
We needed to upgrade huge PHP project and manual changes would take too much time and could stuck us for weeks. Instead, we made an upgrade set with all 25 cases, that changed code for us:
In 4 steps ↓
1. Install Rector to your PHP project
composer require rector/rector-phpoffice --dev
2. Create rector.php config
vendor/bin/rector init
3. Add the spreadsheet set:
use Rector\PHPOffice\Set\PHPOfficeSetList;
use Rector\Config\RectorConfig;
return static function (RectorConfig $rectorConfig) {
$rectorConfig->sets([PHPOfficeSetList::PHPEXCEL_TO_PHPSPREADSHEET]);
};
4. Run Rector on your code
# to see diff with no changes
vendor/bin/rector process src --dry-run
# to make changes happen
vendor/bin/rector process src
If you want to read more, we wrote a short post about it
Related
A while ago, I successfully configured Atom to beautify my PHP using php-cs-fixer, but now I need to go through the same process on another Mac and can't remember exactly how I did it.
As a front-end dev, I'm not a PHP expert, but I understand that the Atom plugin is merely the middleman facilitating the actual fixing using php-cs-fixer, which, by default, it doesn't have access to. Once I installed the fixer, I had to add its location to my PATH variable. The confusing part is that I don't have the fixer installed via Atom (checked ~/.atom/packages) nor Homebrew (confirmed with brew list), however, the file is present in /usr/local/bin. If I move it, Atom returns the original error, so it's definitely using this file:
See https://github.com/FriendsOfPHP/PHP-CS-Fixer for program installation instructions.
Your program is properly installed if running 'which php-cs-fixer' in your Terminal returns an absolute path to the executable. If this does not work then you have not installed the program correctly and so Atom Beautify will not find the program. Atom Beautify requires that the program be found in your PATH environment variable.
Note that this is not an Atom Beautify issue if beautification does not work and the above command also does not work: this is expected behaviour, since you have not properly installed your program. Please properly setup the program and search through existing Atom Beautify issues before creating a new issue. See https://github.com/Glavin001/atom-beautify/search?q=php-cs-fixer&type=Issues for related Issues and https://github.com/Glavin001/atom-beautify/tree/master/docs for documentation. If you are still unable to resolve this issue on your own then please create a new issue and ask for help.
Hide Stack Trace
Error: Could not find 'php-cs-fixer'. The program may not be installed.
at PHPCSFixer.module.exports.Beautifier.commandNotFoundError (/Users/ourcore/.atom/packages/atom-beautify/src/beautifiers/beautifier.coffee:204:14)
at /Users/ourcore/.atom/packages/atom-beautify/src/beautifiers/beautifier.coffee:304:22
at tryCatcher (/Users/ourcore/.atom/packages/atom-beautify/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/Users/ourcore/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:510:31)
at Promise._settlePromise (/Users/ourcore/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:567:18)
at Promise._settlePromise0 (/Users/ourcore/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:612:10)
at Promise._settlePromises (/Users/ourcore/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:687:18)
at Async._drainQueue (/Users/ourcore/.atom/packages/atom-beautify/node_modules/bluebird/js/release/async.js:138:16)
at Async._drainQueues (/Users/ourcore/.atom/packages/atom-beautify/node_modules/bluebird/js/release/async.js:148:10)
at Async.drainQueues (/Users/ourcore/.atom/packages/atom-beautify/node_modules/bluebird/js/release/async.js:17:14)
at process._tickCallback (internal/process/next_tick.js:103:7)
which php-cs-fixer returns /usr/local/bin/php-cs-fixer and my PATH variable currently contains /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/ourcore/.atom/packages/php-cs-fixer.
I guess my questions are, how is the fixer working if the PATH variable seems to be pointing to it in a different location, and how did it end up where it is? Does the location in my PATH matter at all, or does the Atom plugin know to look in /usr/local/bin? I just want to fully understand the entire process before repeating it.
EDIT: On further testing, I removed the Atom directory from my PATH and it didn't affect the plugin, so then I copied the file into the same directory onto the second Mac and it ran without issue, without needing to edit the PATH. Does the fixer file someone inform the OS?
Well first test "which php-cs-fixer" or "where php-cs-fixer" (depending on what os you're running) and if nothing is returned in the terminal then there actually is something wrong on the installation and the best thing to do is to manually install it.
Head to https://github.com/FriendsOfPHP/PHP-CS-Fixer and download it from there and follow the installation steps, after that it should all be good
Can someone with a working Zend/PHPUnit installation tell me how PHPUnit.bat should read?
I have installed PEAR and PHPUnit, but PHPUnit.bat appears to have an error in its code.
Having worked through a few issues, I no longer get 'PHPUnit is not a recognised command' error. But if I now call "PHPUnit" in the command line nothing at all happens except the command prompt reappears. Indicating some code may have run.
I did some reading and PEAR should be calling a .bat file in 'c:\zend\zendServer\bin'. I opened this and there is a very short block of code.
if "%PHPBIN%" == "" set PHPBIN=c:\zend\zendserver\bin\php.exe
if not exist "%PHPBIN%" if "%PHP_PEAR_PHP_BIN%" neq "" goto USE_PEAR_PATH
GOTO RUN
:USE_PEAR_PATH
set PHPBIN=%PHP_PEAR_PHP_BIN%
:RUN
"%PHPBIN%" "C:\Zend\zendServer\bin\\phpunit" %*
The final line looks incorrect, notably the double slash. I have tried various derivations such as 'bin\pear\phpunit etc', but are not sure where this should be pointing.
Can anyone with a working ZendServer/PHPUnit installation tell me how this line should read.
Also, I should also ask, is calling 'PHPunit' in the cmd line the best way to test if the package has installed correctly. Ideas appreciated. The PEAR install call suggested the install should be working fine.
UPDATE
I just created a new project through the zend framework CLI tool and got a note that PHPUnit was not found in my include_path. I have both PEAR and PHP on my include path do I need something else?
UPDATE
I found this post on a potential test Getting PHPUnit Working - Include Path not set correctly?, which provides a way to test phpUnit. I saved the suggested PHP script in my htdocs folder and tried to call it with PHPUnit. Once again no response, which seems to suggest that there is a n error in my PHPUnit.bat file.
Okay this has been a nightmare, but I think I have a solution for anyone facing the same issues.
Question One: how do I test if PHPUNit is working.
Answer: typing PHPUnit into the cmd line will give you a list of all the commands and so acts as a good test as to whether the install has worked.
Question Two: What should PHPUnit.bat look like.
The text above is correct and the extra slash in PHP.bat does not affect the output as ta.speot.is notes.
Solution to get install working:
The issue in this case related to an anomaly with Zend Server. A change to the php config file PHP.ini does not seem to get picked up by the server. It appears that Zend stores the path variables somewhere else. I noted that the changes to the include_path had not been picked up and changed it through the GUI server interface provided with the install.
PHPUnit is now working correctly.
For those struggling with an install I would add two lessons to add to the huge range of posts on the topic.
1) if you have ever had Zend on your computer. Beware an uninstall leaves trace files that can complicate later installs.
2) There is PHPUnit.ini file that gets saved in the c:\windows directory be sure to delete this before starting the install.
3) The following link is an excellent set of instructions http://www.zendexperts.com/2011/06/21/how-to-install-zend-server-ce-pear-phpunit/.
The only change I would make is when using go-pear.php to install PEAR, do not activate errors as suggested in the post, otherwise the interface does not seem to work and issues a large number of errors in the PEAR php.
Hope this helps someone save a couple of days.
I am new to both PHP and Java. Currently I am working on a project which call java class and its methods in the PHP code. I am creating a proof of concept for this. The problem is I am not able to connect custom class I have created in java. More over it could be said I don't know how to do it. I have used java.inc and javabridge.jar files to connect to the system classes but not able to connect to a simple class.
The step I have followed is:
Created a java package, class called clsForPHP and it has a method sum() which takes 2 parameters and returns integer value. (This is created using MyEclipse IDE)
Now I am trying to call this function from PHP. I have copied the jar file containg the package to PHP project. (Eclipse- Helios is the IDE)
$d= new java("clsForPHP.class");
Please help!! I have searched a lot but couldn't able to find a proper solution. What I think is this package should be added in the java.inc file but I don't know how to do it.
First of all install Tomcat6 and Java in you Unix box. Most probably your Tomcat will be on 8080 port. Now Download JavaBridge.war from http://php-java-bridge.sourceforge.net/pjb/ unzip it. Then from WEB-INF/lib folder copy JavaBridge.jar ,php-servlet.jar and php-script.jar in lib folder of Tomcat. Then copy JavaBridge.war in your Tomcat6 webapps folder and restart your tomcat6 service which will deploy automatically JavaBridge folder in your webapps
Now try to browse http://localhost:8080/JavaBridge/. If you get working than your PHP/Java Bridge installed. First Part is over.
Now make test page in your apache as below
<?php
require_once("http://localhost:8080/JavaBridge/java/Java.inc");
echo java("java.lang.System")->getProperties();
?>
and run it. If it works then you can start working with your work. If it not work then you have problem with you php.ini file. Try to make allow_url_once=on in your php.ini.
Now just copy your java jar file in tomcat /webapps/JavaBridge/WEB-INF/lib/ folder
and Just always put following line in your page where ever you want java to work
require_once("http://localhost:8080/JavaBridge/java/Java.inc");
$yourObj = Javav("your java class");
$yourObj->yourMethod();
$yourObj->setProperty("xxx");
Hope this can help you out.
IF you have still any problem get back.
Yea it will throw error because you must not have copied your java compiled file may be your jar file in PHP / Java Bridge.
You can to do in following 2 options way
If you have define your CATALINA_HOME then copy
$CATALINA_HOME/webapps/JavaBridge/WEB-INF/lib
If you have not define your CATALINA_HOME then copy
/var/lib/tomcat6/webapps/webapps/JavaBridge/WEB-INF/lib
Path which I am telling it assumes that you have install tomcat6, may be your tomcat webapps folder may be in different path.
Note - this problem is resolved, but I'm posting here to find insight into what was happening because I don't understand.
My shared host's default configuration is PHP 5.2.17. When I asked them if I could upgrade to 5.3.X they said sure, and to quote:
A handler for PHP 5.3 is added to our shared and reseller servers for
those who wish to utilize it. In order to utilize this handler, you
will need to add the following code to your .htaccess file:
Action application/x-hg-php53 /cgi-sys/php53
AddType application/x-hg-php53 .php
To elaborate further on why we do not currently have this by default,
it is due to compatibility issues of older PHP scripts with the new
5.3 version. So, to prevent breaking the older scripts on our client's sites we have left the default PHP version as 5.2.X.
So I did that and quickly discovered that this killed my sites using PDO. Calling new PDO(); resulted in class not found errors in the log.
The shared host's support response was:
Our PHP 5.3 installations do have PDO enabled already. The issue here
appears to be caused by a custom php.ini based on the php.ini for PHP
5.2, so it attempts to load the PHP 5.2 modules instead of the PHP 5.3 modules.
ok seems reasonable, says I, now go ahead and fix that!
They updated the .ini file, and added the handlers to my .htaccess, and...
Your site appears to load correctly, but let us know if you find any problems.
which was true, now the main site and PDO were working fine and a phpinfo() check indeed confirmed I was on 5.3.8, but then several hours later a cron job died a fiery death:
[16-Dec-2011 03:00:01] PHP Warning: PHP Startup: Unable to load dynamic library '/opt/php53/lib/php/extensions/no-debug-non-zts-20090626/pdo.so' - /opt/php53/lib/php/extensions/no-debug-non-zts-20090626/pdo.so: undefined symbol: gc_remove_zval_from_buffer in Unknown on line 0
and the error log from the cron job directory:
[16-Dec-2011 03:00:01] PHP Warning: require_once(../pghqClasses/PDO.php) [function.require-once]: failed to open stream: No such file or directory in /home/XXXXXX/pghqIncs/initCron.php on line 19
So once again the PDO calls were failing, but this time only for cron jobs.
The support team's final reply was:
I've seen this behavior before, where relative paths in PHP scripts don't point to the right place. According to the PHP manual, one if the differences between the CLI php and other interfaces for PHP is that CLI PHP won't change directories to that of the script. http://www.php.net/manual/en/features.commandline.differences.php
To fix this, I've added the line:
chdir( dirname ( FILE ) );
to the top of your cron script so that, when executed, it WILL change directories to that of the script, therefore making the relative path work. When run from the website, this line will essentially do nothing, but it should make your cronjob run correctly.
And it does indeed work. My cron jobs are running smoothly, and my main site is good, and everyone is happily on 5.3.8, but that last bit of trouble-shooting totally lost me and I'd like someone to explain to me how the includes can fail for a cron but NOT for a public_html script, why we're chdir(), and so on?
Thank you, and sorry about the length...
The problem is that the cron job, which uses the command-line PHP executable is running with the current directory as the location of the PHP executable, or the home folder of whichever account is running the job. Therefore, any relative paths in the script are resolved relative to that location, rather than the directory containing the script.
By adding the the chdir() call you're setting the current directory to the location expected by the script, and therefore your relative paths resolve correctly.
Since some time I'm having problems with Eclipse. When opening any file with a class which extends one specified class (Presenter), an error occurs:
Multiple problems have occurred http://img64.imageshack.us/img64/9678/screeneclipseproblems.png
Internal Error http://img202.imageshack.us/img202/5131/screeneclipseproblemspr.png
I've noted, that problems occurs only when loading the mentioned class - Presenter.
When I delete "extends Presenter" or when I delete the file, which contains class Presenter, the problems dissappear.
Class Presenter is part of the PHP framework Nette, so you can see the contents of this class here:
http://api.nette.org/1.0/__filesource/fsource_Nette-Application__ApplicationPresenter.php.html
I can provide contents of LOG files, if that may help, but those are large (over 1 MiB).
I faced the same problem. Here is the way to fixe it:
First goto [workbench_directory]/.metadata/.plugins/ - remove the folder named "eclipse.org.core.resources" and keep a copy of it.
Now go to the eclipse directory using CommandPrompt(Windows) or Terminal(in linux,mac)
write the command $ eclipse -clean ---> this will start your eclipse application.
Now close the eclipse application and restore the "eclipse.org.core.resources" folder that you removed in the First step.
That's it! You won't see the problem.
What exact version of Eclipse and PDT are you using?
There was a bug last month about that kind of error: bug 316876, but it appears to be fixed in PDT-2.2.0.v20100616.
Check also your eclipse.ini like, for instance, this ones (depending on your eclipse version).
You can increase VM stacksize and check. But a better solution would be to work out how to avoid recursing so much.
Add the flag -Xss1024k in the VM arguments for starting Eclipse (in eclipse.ini file in your Eclipse installation folder).
You can also increase the stack size in MB, by using -Xss1m for example.
I'm running Eclipse Indigo. I've adding the following to my eclipse.ini file as I didn't have them in there.
-Xmx1024m
-Xss1m
I haven't been able to salvage my Eclipse installation. The Error logs in Eclipse pertain to issues with the OSGI and Team plugin. I can try uninstalling these.