I'm rebuilding my xampp and CI environment (on win7) from scratch but am having trouble running phpdoc through phing. In particular, Phing is looking to phpdocumentor.ini in a place that doesn't exist (and never has).
Phing and PhpDocumentor have both been installed through Pear, paths setup seems fine, and have these versions:
php version 5.4.7
pear version 1.9.4
phpdoc version 2.0.1
phing version 2.6.1
Relevant paths on the system are:
H:\xampp\php;
H:\xampp\php\pear;
On my sample project:
I can run phpdoc without a hitch, for example: phpdoc -d apps -t docs runs fine.
Here's my phpdoc task, which has worked well in the past:
<phpdoc title=Docs" destdir="${docsdir}" sourcecode="false" output="HTML:frames:earthli">
<fileset dir="./apps">
<include name="**/*.php" />
</fileset>
<projdocfileset dir=".">
<include name="README" />
<include name="INSTALL" />
<include name="CHANGELOG" />
</projdocfileset>
</phpdoc>
When I run Phing, phpdoc fails with the following notice:
Parsing configuration file phpDocumentor.ini...
(found in C:\php\pear\data/PhpDocumentor/)...
ERROR: cannot open phpDocumentor.ini in directory
-Is phpdoc in either the path or include_path in your php.ini file?
There is no c:\php... directory, and never has been, so I don't know where this has come from.
I can only get this working if I create the whole PHPDocumentor structure Phing anticipates on C: but I'd ideally like to get the ini file's anticipated location changed so I have everything on the one drive.
Is there any way I can inform Phing of the true location of my phpdocumentor.ini?
I've not found this specific problem listed on SO, but am hopeful someone else has seen and rectified this. The Phing site docs/forum/trac don't list any recent reports of this problem.
Thanks all
It looks like you're trying to use phpDocumentor 2.x and seeing some behavior from what looks like phpDocumentor 1.x. Perhaps there is some 1.x code that came with the XAMPP source that is lingering and affecting your ability to run 2.x cleanly.
In considering the Phing angle, in glancing at the Phing manual, it looks like the correct Phing task to use for phpDocumentor 2.x is the DocBlox task [1] rather than the old PhpDoc task.
[1] -- http://www.phing.info/docs/guide/stable/apcs52.html.
Downloading the latest zip archive release of XAMPP for Windows I see that the file:
\xampp\php\pear\PhpDocumentor\phpDocumentor\Setup.inc.php
the function parseIni() refers directly to the aforementioned path:
enter code herephpDocumentor_out(" (found in " . 'C:\php\pear\data/PhpDocumentor' . PATH_DELIMITER . ")...\n");
So its more likely to be a XAMPP problem than any of the components I've been upgrading or force-reinstalling.
Related
Here is a weird problem i'm facing; after updating Joomla to the latest version, website failed to up load but, as i've made a backup manually from these folders:
administrator
bin
cli
components
includes
layouts
libraries
modules
plugins
yt-assets
and all the root files, after restoring the backup still the website is not loading and just says
"Fatal error: Cannot redeclare jblogerror() in on line 0" !
Any suggestion? Thank you.
Apparently, the version of jBlog you are using is loading its attempting to load its own classes twice.
Let's assume the jBlog developers already fixed it and you carelessly ignored the warning to ensure all your extensions are compatible before updating.
Are you able to access administrator? Simply go there and upgrade jBlog including any modules.
Else, the issue lies within a plugin. In order to access the administrator and perform the update, you will need to manually disable the offending plugin.
A simple way is to rename its folder: start from plugins/system then plugins/content hopefully you'll have spotted it by then. Look into the subfolders of each and spot any that may be relevant to jBlog (or grep through the folder to locate the specific string)
If you have console access, simply run
# grep -rl jblogerror plugins/system
and you should see all the files that include such string, just rename their main plugin folder. But you could also do all this through ftp and guessing.
I am facing below issue in my entire installations of M2.
[InvalidArgumentException]
There are no commands defined in the "setup" namespace.
weird thing is I installed fresh Xampp and set up new M2 instance, then also same issue persists. It started coming suddenly and I have tried all available solutions like setting permissions to folders and trying -vvv option and list command to find exact issue.
till now no success. My whole day wasted in debugging this only and now I am running out of thoughts.
If anyone have ideas?
I am using PHP 5.6 and Magento EE 2.1.7
Try Following Solution :
Solution 1 :Please mention setup_version in your module.xml file. Your module.xml file looks like:
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../../lib/internal/Magento/Framework/Module/etc/module.xsd">
<module name="Vendor_Module" setup_version="1.0.0"/>
</config>
Solution 2 : You need to give full permission to both var and pub folders recursively.
sudo chmod -R 777 var pub
if above solution not work then try following link
https://magento.stackexchange.com/questions/103774/magento-2-there-are-no-commands-defined-in-the-setup-namespace-on-windows
The reason for this error can be seen in the command output: php -f bin/magento.
This will work for most errors like There are no commands defined in the "..." namespace..
A fairly common cause is an error in xml files e.g. VendorName/ModuleName/etc/config.xml.
I'm trying to get JavaFX Ant to package up my (Swing) code with the JRE for Mac OS X.
I've got almost everything working, but I can't figure out how to include jre/bin/java. It looks like all the other relevant stuff from jre/ is included (e.g. all the jre/lib/).
Here's my ant task:
<fx:deploy outdir="${appdir}" outfile="${appname}" nativeBundles="image">
<fx:info title="${appname}" vendor="${vendor}"/>
<fx:application name="${appname}"/>
<fx:bundleArgument arg="icon" value="${appname}.icns"/>
<fx:resources>
<fx:fileset dir=".">
<include name="${objar}"/>
</fx:fileset>
</fx:resources>
<fx:platform basedir="${jdk-base}"/>
</fx:deploy>
Is there a way to get to include jre/bin/java? Or should it already be doing this and so I should look for something screwed up on my system?
Is there a way to add stuff via scripting (e.g. like the "package/macosx/post-image.sh" mechanism)?
Is the ant-javafx source available somewhere?
Any other suggestions?
thx.
I am testing out Pelican for my personal blog use but I am stuck with the use of plugins.
Apparently, the pelicanconf.py file is not picking up my plugins.
Here's a snippet of my pelicanconf.py:
THEME = '/Users/namely/Public/MyPersonalWorkspace/static_blog/static-blog/pelican-themes/pelican-bootstrap3'
PLUGINS_PATHS = ["./plugins","plugins","./pelican-plugins","pelican-plugins","/Users/namely/Public/MyPersonalWorkspace/static_blog/static-blog/pelican-plugins"]
PLUGINS = ["sitemap"]
My pelican setup for theme is correct since I am using the theme correctly. But somehow, it is not reading my plugin directories. The following is my folder structure:
static-blog/
content/
output/
pelican-plugins/
sitemap/
__init__.py
sitemap.py
Readme.rst
plugins/
sitemap.py
pelican-themes/
pelican-bootstrap3/
# and all pelican-bootstrap3's files
pelicanconf.py
publishconf.py
develop_server.sh
fabfile
Makefile
I am using Pelican 3.4, on a Macbook Air ( OSX 10.9.4 ), Python version 2.7.5
I am using a list of directories for PLUGIN_PATHS since all the directories didn't work ( either individually or in a list, relative or absolute. ).
My pelican installation is working fine since I can run my blog. It's just that the plugins are not working somehow. For plugins, I simply did a git clone from https://github.com/getpelican/pelican-plugins.
The error message I received was:
ERROR: Can't find plugin `sitemap`: No module named sitemap
Any advice is great!
Thank you all!
It might be something as simple as a typo in your settings file. As noted in the docs, the name of the relevant setting is PLUGIN_PATHS, whereas your settings file appears to contain PLUGINS_PATHS (note the spurious S).
Can phpDocumentor be used to generate HTML docs for some legacy code that does not necessarily conform to its standard?
I'd like to generate some preliminary documentation for an old code tree and later on start improving my comments and add the appropriate # tags as I get fluent with phpDocumentor. I've never used this piece of software before and the examples I've found focus on how to write new code that conforms to its syntax and generate HTML file by file with the -f parameter.
I've installed latest phpDocumentor through the PEAR command line installer and tried this little *.bat file on Windows XP:
#echo off
phpdoc ^
--directory "\\server\project\trunk" ^
--target "C:\tests\project-doc"
... but this is all I get:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
directory: '' not found
I've also tried mapping the UNC path to a drive letter:
#echo off
phpdoc ^
--directory "I:\" ^
--target "C:\tests\project-doc"
... but:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
a target directory must be specified
try phpdoc -h
This error message is the same if I create "C:\tests\project-doc" before.
What's exactly wrong in my syntax?
phpDocumentor can indeed run against "undocumented" code. It builds its docs based on the code itself, and uses the docblocks as additional info (and additional organization, in the case of #package and #subpackage tags).
I'd suggest starting with phpDocumentor against your existing code, and work towards clearing out the warnings you see in the errors.html file that results -- this file is generated in the top level of your output docs, but there isn't any link to it from the output docs.
Once you have those cleared, you can start running phpDocumentor with the -ue argument (--undocumentedelements), which will add new warnings to errors.html, highlighting (in much greater detail) things that still need to be documented in docblocks.
Now, as for the issue you're having trying to run the program against code on a shared drive, I'm not sure what's wrong there. The script is clearly able to execute PHP and find the phpDocumentor code itself. You might try putting the arguments in the same line, rather than using the ^ as a line-feed escape character, and perhaps remove the quotes around the paths (since no spaces exist in the paths).
I think I've found what the issue is. The parameter parser is very picky and it doesn't like neither UNC paths nor bare root directories. If I replace this:
--directory "I:\"
... with this:
--directory "I:\."
... it finally starts running.
I suppose it's a bug. Their bug tracker doesn't seem to be public so I don't know if it's a known issue.