Phpdocumentor: Empty Documentation Being Generated

[robertmain]

Running 3.0.0-alpha and I'm getting just an empty set of docs. No warnings. No errors. No exceptions. Nothing. Just an empty template. Zilch. Like so:

Expected Behavior

Ideally, it should generate some documentation from my code like the previous version 🙃

Actual Behavior

Just an empty template

Steps to Reproduce the Problem

1. Composer install 3.0.0-alpha1
2. Run phpdoc

Your environment

Include as many relevant details about the environment you experienced the bug in and how to reproduce it.
Since many issue might only occur on a specific code base it would be very helpfull if you link to your project
or add any code that is involved in to the issue.

• Version used: 3.0.0-alpha1
• Install method: Composer
• php version: 7.1
• Operating system and version (e.g. Ubuntu 16.04, Windows 7): Windows 10
• Link to your project: https://github.com/robertmain/codeigniter-starter

[AnrDaemon]

Keep error logging full…

Collecting files .. PHP Warning:  preg_match(): Compilation failed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 10 in phar://…/phpDocumentor-3.0.0-alpha1.phar/vendor/phpdocumentor/flyfinder/src/Specification/InPath.php on line 54

[AnrDaemon]

It's the very first line. Set error_log = -1; display_errors = On.

[jaapio]

Think it is already fixed. But we are still working on some other issues before we can release a new alpha release. You could try our develop branch

[roopemerikukka]

I'm also getting this bug. It seems that the 3.0.0-alpha1 is the only version I'm able to get when using via Docker. Could you please add some previous versions to DockerHub also?

[thelounge-zz]

first it don't understand things like "--filename="/www/phpincludes/global.php" any longer
Warning: file_get_contents(/www/phpincludes/global.php): failed to open stream: No such file or directory in phar:///mnt/data/www/thelounge.net/contentlounge/updateservice/phpDocumentor.phar/vendor/phpdocumentor/reflection/src/phpDocumentor/Reflection/File/LocalFile.php on line 44

second the following call also leads in empty docs as described in this bugreport

/usr/bin/time -f "%E" php -d "extension=tokenizer.so" "$CMS_UPDATE_SERVICE_LOCATION/phpDocumentor.phar" run --force --progressbar --cache-folder="/tmp" --encoding="ISO-8859-1" --directory="$CMS_UPDATE_SERVICE_LOCATION/package" --filename="/www/phpincludes/newsletter.php" --ignore="modules/blog/tagcloud.php" --target="$CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/contentlounge" --title="ContentLounge - Technische Referenz" --defaultpackagename="ContentLounge" --template="clean"

[jaapio]

I'm going to split this issue in several sub issues. The original report is fixed in the upcoming alpha2 release.

Issue reported by @cixtor seems to be a different issue with the template which doesn't show files only containing a function. The html file is generated but somehow it is not showing up in the menu. #1978

The issue reported by @thelounge-zz needs to be checked. We changed quite a lot in the upcoming release. It could be that this is resolved as well because we had some issues with the new file resolver. #1979

[thelounge-zz]

please make another alpha available as phar - https://github.com/phpDocumentor/phpDocumentor2/releases -> v3.0.0-alpha1 -> 24 Dec 2017 is terrible outdated and probably the current trunk just works and you can get that confirmed by users that way

[AeonDigital]

I had the same problem when I trying to create the documentation with php 7.1 syntax, I noticed that phpDocumentor works when I put "\" in front of the parameter types.

Ex:

@param \int $valid Works as espected.
instead of
@param int $invalid Do not works ... why? !!

---

When I specify an array of a certain type I also encounter errors:

ex:

@param \DateTime[] $dtColl Array / Collection of DateTime objects.

In the documentation the result exposes the type as being:
\DateTime | string | int

---

Will these behaviors be fixed in the future or should I change my code documentation to use the "\" in front of the parameter type?

What about using the notation "ArrayOfObjects[]", should I continue to use it or mute it to just "array"?

[jaapio]

The behavior you described is a separate bug that will be addressed. Thanks for reporting!

[jaapio]

Please find our new release on the releases page.

[thelounge-zz]

don't even work basically - besides that --target is still empty --directory don't work at all, there are listed a ton of files which are by far in that directory but subfolders of where the par-file is located

AFI - Technische Referenz
23:36:23 INFO [app] One of the project's settings have changed, forcing a complete rebuild [] []
23:36:23 INFO [app] Starting to parse file: cms_demo/api.php [] []
23:36:23 INFO [app] Parsing cms_demo/api.php [] []
23:36:23 INFO [app] Starting to parse file: cms_demo/api_cache.php [] []
23:36:23 INFO [app] Parsing cms_demo/api_cache.php [] []
23:36:23 INFO [app] Starting to parse file: cms_demo/api_captcha.php [] []

[harry@srv-rhsoft:~/updateservice]$ cat makedoc.sh

!/usr/bin/bash

Globale Location-Config einbinden ($CMS_UPDATE_SERVICE_LOCATION)

. /scripts/cms-updateservice-location.sh

if [ "$CMS_UPDATE_SERVICE_LOCATION" != "" ]; then
php "$CMS_UPDATE_SERVICE_LOCATION/phpDocumentor.phar" --version
echo ""

if [ -d /Volumes/dune/www-servers/www.alufenster.at ]; then
echo -e "\e[32mAFI - Technische Referenz\e[0m"
rm -rf $CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/afi/*
/usr/bin/time -f "%E" php -d "zend.enable_gc=0" "$CMS_UPDATE_SERVICE_LOCATION/phpDocumentor.phar" run --force --progressbar --cache-folder="/tmp" --encoding="ISO-8859-1" --directory="/Volumes/dune/www-servers/www.alufenster.at" --filename="/www/phpincludes/global.php,/www/phpincludes/newsletter.php,/www/phpincludes/fwx_module_ffmpeg.inc.php" --target="$CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/afi" --title="AFI - Technische Referenz" --defaultpackagename="ContentLounge" --template="clean"
rm -rf /tmp/phpdoc-cache
find "$CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/afi/files" -type f -name *.txt -delete
echo ""
fi

echo -e "\e[32mContentLounge - Technische Referenz\e[0m"
rm -rf $CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/contentlounge/*
/usr/bin/time -f "%E" php -d "zend.enable_gc=0" "$CMS_UPDATE_SERVICE_LOCATION/phpDocumentor.phar" run --force --progressbar --cache-folder="/tmp" --encoding="ISO-8859-1" --directory="$CMS_UPDATE_SERVICE_LOCATION/package" --filename="/www/phpincludes/newsletter.php" --ignore="modules/blog/tagcloud.php" --target="$CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/contentlounge" --title="ContentLounge - Technische Referenz" --defaultpackagename="ContentLounge" --template="clean"
rm -rf /tmp/phpdoc-cache*
find "$CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/contentlounge/files" -type f -name *.txt -delete
echo ""

echo -e "\e[32mGlobale Includes - Technische Referenz\e[0m"
rm -rf $CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/phpincludes/*
/usr/bin/time -f "%E" php -d "zend.enable_gc=0" "$CMS_UPDATE_SERVICE_LOCATION/phpDocumentor.phar" run --force --progressbar --cache-folder="/tmp" --encoding="ISO-8859-1" --filename="/www/phpincludes/global.php,/www/phpincludes/fwx_module_ffmpeg.inc.php" --ignore="global_class.phpmailer.php,global_class.smtp.php" --target="$CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/phpincludes" --title="Globale Includes - Technische Referenz" --defaultpackagename="rh-php-runtimes" --template="clean"
rm -rf /tmp/phpdoc-cache
find "$CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/phpincludes/files" -type f -name *.txt -delete
echo ""

# Temp-Files und leere Ordner am Ende entfernen
rm -rf "$CMS_UPDATE_SERVICE_LOCATION/build/"
find "$CMS_UPDATE_SERVICE_LOCATION/documentation/code-referenzen/" -type d -empty -delete
else
echo "CMS_UPDATE_SERVICE_LOCATION NOT SET"
exit 1
fi

[AnrDaemon]

Please find our new release on the releases page.

In Filesystem.php line 614:

  Cannot use object of type phpDocumentor\DomainModel\Path as array

Did you test it?…

[jaapio]

We are running several tests against the released phar. Not everything is tested yet. So The commands like @thelounge-zz provides do help us to identify where issues are. For those situations extra tests are added.

[AnrDaemon]

Well, my case wasn't anything specific, I just told it to run through src/ directory, and specified output and cache directory. Tried with and without --force, made no difference.

Literal command line

"phpDocumentor-3.0.0-alpha2.phar" run --directory="src/" --target=".output/" --cache-folder=".cache/" --sourcecode 2>&1

Literal output

09:18:48 ERROR     [console] Error thrown while running command "run --directory "src/" --target ".output/" --cache-folder ".cache/" --sourcecode". Message: "Cannot use object of type phpDocumentor\DomainModel\Path as array" ["error" => Error { …},"command" => "run --directory "src/" --target ".output/" --cache-folder ".cache/" --sourcecode","message" => "Cannot use object of type phpDocumentor\DomainModel\Path as array"] []
09:18:48 ERROR     [console] Error thrown while running command "run --directory "src/" --target ".output/" --cache-folder ".cache/" --sourcecode". Message: "Cannot use object of type phpDocumentor\DomainModel\Path as array" ["error" => Error { …},"command" => "run --directory "src/" --target ".output/" --cache-folder ".cache/" --sourcecode","message" => "Cannot use object of type phpDocumentor\DomainModel\Path as array"] []

In Filesystem.php line 614:

  Cannot use object of type phpDocumentor\DomainModel\Path as array  


project:run [-t|--target [TARGET]] [--cache-folder [CACHE-FOLDER]] [-f|--filename [FILENAME]] [-d|--directory [DIRECTORY]] [--encoding [ENCODING]] [--extensions [EXTENSIONS]] [-i|--ignore [IGNORE]] [--ignore-tags [IGNORE-TAGS]] [--hidden] [--ignore-symlinks] [-m|--markers [MARKERS]] [--title [TITLE]] [--force] [--validate] [--visibility [VISIBILITY]] [--defaultpackagename [DEFAULTPACKAGENAME]] [--sourcecode] [-p|--progressbar] [--template [TEMPLATE]] [--parseprivate] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [-c|--config [CONFIG]] [--log [LOG]] [--] <command>

PHP 7.1.16 (Win64 native and Cygwin64, both failing identically)

[jaapio]

Thanks, it looks like there is an issue in the config building. I need to investigate this, but mean while I can recommend you to use a config file to parse your projects which does work.

phpdoc.dist.xml or phpdoc.xml

<?xml version="1.0" encoding="UTF-8" ?>
<phpdocumentor>
    <parser>
        <default-package-name>My Project</default-package-name>
        <target>.cache</target>
    </parser>
    <transformer>
        <target>.output</target>
    </transformer>
    <files>
        <directory>src/</directory>
    </files>
    <transformations>
        <template name="clean" />
    </transformations>
</phpdocumentor>

[AnrDaemon]

Ok, this is way beyond my ability of understanding.
Under windows native PHP it is failing with

10:31:53 WARNING   [php] Warning: mkdir(): No such file or directory ["exception" => ErrorException { …}] []
10:31:53 WARNING   [php] Warning: mkdir(): No such file or directory ["exception" => ErrorException { …}] []
10:31:53 ERROR     [console] Error thrown while running command "project:run --force --sourcecode". Message: "PPCPP:EXC-BADTARGET" ["error" => RuntimeException { …},"command" => "project:run --force --sourcecode","message" => "PPCPP:EXC-BADTARGET"] []
10:31:53 ERROR     [console] Error thrown while running command "project:run --force --sourcecode". Message: "PPCPP:EXC-BADTARGET" ["error" => RuntimeException { …},"command" => "project:run --force --sourcecode","message" => "PPCPP:EXC-BADTARGET"] []

In Parser.php line 134:

  PPCPP:EXC-BADTARGET  


project:run [-t|--target [TARGET]] [--cache-folder [CACHE-FOLDER]] [-f|--filename [FILENAME]] [-d|--directory [DIRECTORY]] [--encoding [ENCODING]] [--extensions [EXTENSIONS]] [-i|--ignore [IGNORE]] [--ignore-tags [IGNORE-TAGS]] [--hidden] [--ignore-symlinks] [-m|--markers [MARKERS]] [--title [TITLE]] [--force] [--validate] [--visibility [VISIBILITY]] [--defaultpackagename [DEFAULTPACKAGENAME]] [--sourcecode] [-p|--progressbar] [--template [TEMPLATE]] [--parseprivate] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [-c|--config [CONFIG]] [--log [LOG]] [--] <command>

Under Cygwin PHP it starts, but seems to completely ignore the XML and parse everything, even its own cache directory, and then hangs.

Doesn't seems to matter if I use <phpdoc> or <phpdocumentor> root tag in the project file.

[AnrDaemon]

'kay, it picked phpdoc.dist.xml and complained that it had <phpdoc> root tag at the moment.
But still failed to understand configuration, even though I cross-referenced everything against documentation just to be on the safe side.

[thelounge-zz]

config files are horrible to script - what we have here with all the shell-vars is a distribution system which includes a machine-specific env-include and everything else is using that vars

so basicaly manage subversion, cms-deployment on a unlimited amount of hosts and egnerating docs just works by copy the one and only folder containing everything from sources, configs, maintainance, documentation and so on - the idea behind is "bus-factor" - patches to the code-base are only applied by me and distribution only happens from one of my machines which are in sync all the time - but when a lightnig strikes me one can start from his copy to replace me entriely without any additional steps

[AnrDaemon]

Please post a separate issue, if you have concerns.
Your rant is not relevant to the present issue in the slightest.

[thelounge-zz]

the script above works with the current stable version which is lacking PHP7.1/7.2 support and so only generates half of the docs but now it creates a empty documentation, iterates completly wrong source folders and so on

so how is it not relevant to the issue "Empty Documentation Generated"

i tell you another rant: you guys obviously violated the development rule to split between complete refactoring and add support for a few new language constructs while nullable types where proposed 3 years ago or so in php upstream

[jaapio]

Feel free to create a PR to the master branch to add support for php 7. in 2.10 :+1:

You are using an opensource project, which is maintained by a small group of people. If you want to contribute to speed up our work please join us.

[AnrDaemon]

/patiently awaiting new alpha ^______________________^

[AnrDaemon]

P.S.
Is this fine that new alpha is nearly 4 times smaller in size than previous, or even v2 .phar ?

[jaapio]

@AnrDaemon yes we switched to humbug/box which compresses the phar contents by default.

[redaxmedia]

I also have issues with PHP 7.1 while generating XML report... some PHP files are working but then there are strange issues like that one:

  <file path="Head/Script.php" generated-path="Head.Script.html" hash="1f73835509e251197e54f0dcb3b3b0fb" package="Default">
    <docblock line="0">
      <description></description>
      <long-description></long-description>
      <tag name="package" line="0" description="Default"/>
    </docblock>
    <parse_markers>
      <error line="0" code="PPC:ERR-50000">No summary was found for this file</error>
    </parse_markers>
  </file>

It does not find a namespace or even a class.

[thelounge-zz]

are you mentally ill?

half of the docs are still empty and god knows what's wrong ginving the amounf of shit

[2019-12-13 00:22:58] php.INFO: User Deprecated: Please use getType {"exception":"[object] (ErrorException(code: 0): User Deprecated: Please use getType at phar:///mnt/data/www/thelounge.net/contentlounge/updateservice/phpDocumentor.phar/src/phpDocumentor/Descriptor/ArgumentDescriptor.php:75)"} []

[thelounge-zz]

come on and fuck yourself

In DocBlockFactory.php line 110:

trim() expects parameter 1 to be string, null given

[thelounge-zz]

are you guys really mentally ill?

this shit on 7.4.0 takes 5 seconds to fix, commit and start the generation of a fresh .phar file
frankly, that is one example why i don't use noramlly anything written in PHP from someone i can't punch physically straight in the face

that bullshit don#t work properly for years and coll that it's for free, giben that it's not worth any money, call me when it's at a point to waste money....

[2019-12-13 01:52:56] php.INFO: Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead {"exception":"[object] (ErrorException(code: 0): Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead at phar:///mnt/data/www/thelounge.net/contentlounge/updateservice/phpDocumentor.phar/vendor/twig/twig/src/Template.php:595)"} []
[2019-12-13 01:52:56] php.INFO: Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead {"exception":"[object] (ErrorException(code: 0): Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead at phar:///mnt/data/www/thelounge.net/contentlounge/updateservice/phpDocumentor.phar/vendor/twig/twig/src/Template.php:595)"} []
[2019-12-13 01:52:56] php.INFO: Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead {"exception":"[object] (ErrorException(code: 0): Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead at phar:///mnt/data/www/thelounge.net/contentlounge/updateservice/phpDocumentor.phar/vendor/twig/twig/src/Template.php:595)"} []

[thelounge-zz]

you mororns can't throw "In DocBlockFactory.php line 110: trim() expects parameter 1 to be string, null given" all day long even after one removed every trim() call from a file which stops phpdoc

if i want a static code analyzer i use one, one which works, means it teels you waht may be wrong in the analyzed file and not what is fucked up in itself! tell me what can be optimized even for code wirtten 10 years ago and nobody pays a cent to fix it, i still will fix it but not in line 110 of your bullshit

how do you imaine the future of this shit given it don't work with PHP 7.2 when 7.4 is out?

[thelounge-zz]

and if you want that shit make at least soemhow useable bring back some links to template "clean" - it's ridiculous that most templates are unuseable or throwing errors

[thelounge-zz]

template "old-ocean"
In Sourcecode.php line 52: htmlentities() expects parameter 1 to be string, null given

creep away - nobody used the sourcecoe param at the commandline

[mvriel]

For phpDocumentor 3, we have been hard at work these past few weeks to improve on such issues. Unfortunately, it is mostly the two of us and aside from fixing deprecation messages we also have to address bugs, work towards supporting new language features, introduce new abilities to the application, write documentation, create tests for uncovered parts of the application and more.

To reduce our workload and be able to more swiftly react to discovered and reported issues we have also decided to remove support for XSL-based templates and the templates from phpDocumentor 3.

But bluntly stated: your current stream of reactions are unhelpful and actually detrimental to getting these things fixed. With your tone, you decrease our motivation to work, our motivation to respond to this and even increase stress levels, making burnout something real that happens.

So, know that we are actively working on getting v3 in proper shape and it would be beneficial to the project, and thus everyone who uses it if you leave your personal attacks at the door.

[thelounge-zz]

frankly - i just need one default template which works and have clickable links with as less bloat as possible and no inclusion of the whole source - just generated class dcoumentations and either the file.-comments from packages/files without classes or not mentioned the empty stuff in the naivigation - it's that simple

My last comment here was more that a year ago, i iopgnroed the wohle phpdoc stuff until now in the hope it will become somehow usable as it was until someone decided to start from scratch years ago

[mvriel]

We understand your frustration and as weird as it may sound, we share at least part of it. Last SymfonyCon Jaap and I had extensive talks on how to get this on track and to release phpDocumentor 3 as soon as possible with all that annoyance gone.

For the past weeks we have been taking the following steps:

1. Make the build pipeline more extensive, we now test on Mac, Windows, Linux on PHP 7.2, 7.3 and 7.4 using unit tests and we are fixing the Behat tests that we had been working on.
2. Increase code quality by introducing PHPStan (we are now at level 4), and the Doctrine Coding Standard
3. Reducing the amount of code to support so that we can focus on getting it right, in the past weeks we have cut a number of features and dropped thousands of lines from the project

Things take long, we know. As mentioned, the reality is that we are just the two of us and I have had a total OSS burnout for more than a year. I know this does not help you immediately, but know that we haven't given up but also need to do a lot of work to get there.

[jaapio]

We did some extensive tests with support of multiple users of phpdocumentor. Things are improving now. The first report in #2130 was equal to what was reported in this first post.
Some other issues have been extracted from this issue and need to be checked.

I was able to generate the api docs for the linked project by @robertmain. So I expect this issue to be closed for now.
Feel free to open any new issues when needed. Or when you have any questions about phpdocumentor.

We are not yet back at the level where we were before we started the development of v3. But we are working hard to give you the best possible experience.

Please note that phpDocumentor 3 currently doesn't support multiple root directories. This feature was never intended to be supported and it was a bug in phpdoc v2.
So commands like this:
/opt/phpdoc/build/phpDocumentor.phar run -d src/ -f "/opt/phpdoc/src/phpDocumentor/*.php" -t /opt/phpdoc/user-project/
Will only generate the docs for the files in ./src

The file and directory arguments are meant to filter the directories and files processed by phpdocumentor. and NOT to include external files in your docs. We will add some support for this in the future, but because of a lot of changed internals, we cannot add that in the first release of v3.
We do think that most of our users are not using the command-line this way. Besides that phpdoc v3 will have much more to offer when using proper config files. Since we do believe configuration will always allow you to have a setup per project just like you have for any other tool that is applied on your code.

[thelounge-zz]

https://github.com/phpDocumentor/phpDocumentor/releases still has nothing newer than from last august as phar wich makes it impossible to verify, i dn't even consider install composer and all the deps on any of my systems where phpdoc, roundcube and phpmailer are the only 3rd party code

[jaapio]

If you only took the time to check my latest comment, but here you go. The link to the download that has been verified.

https://github.com/phpDocumentor/phpDocumentor/suites/394838886/artifacts/1057266

[thelounge-zz]

https://github.com/phpDocumentor/phpDocumentor/suites/394838886/artifacts/1057266 gives a Github 404 and i can't see that in your latest comment nor do i expect the download somewhere else than where the "latest" alpha version was to download

about "Please note that phpDocumentor 3 currently doesn't support multiple root directories. This feature was never intended to be supported and it was a bug in phpdoc v2" that worked even 15 years ago given that all my projects using central include folder holding the framework for the whole machine and all 200 running instances

[jaapio]

A fresh one: https://github.com/phpDocumentor/phpDocumentor/suites/397109791/artifacts/1086602

It is documented in the readme: https://github.com/phpDocumentor/phpDocumentor#nightly-builds

We are working on more before we will release a new alpha version. There is no need to release stuff that we are not sure about to release. Since we do have a build each time the pipeline runs. I will agree with me that you only want to provide working release. So that's what we have learned from the past alpha releases.

We will support multiple api's in the future. which is basically the case when you have multiple directories. The support is not there yet. That's why we are naming this v3 and not v2.10. It does contain breaking changes. And if you are developing software for 15 years now you will understand that you need to break with your past sometimes to come up with something better.

[thelounge-zz]

And if you are developing software for 15 years now you will understand that
you need to break with your past sometimes to come up with something better.

not that dramatcially as phpdoc did with 2 as well as 3 and nothing usebale since PHP 7.2 was released but anyways: "\Content-Lounge-API" is not a valid Fqsen

/**

• @package Content-Lounge-API
  */

15:00:18 ERROR [console] Error thrown while running command "run --force --quiet --no-debug --cache-folder='/tmp/phpdoc-cache' --encoding=ISO-8859-1 --directory='/www/thelounge.net/contentlounge/updateservice/package' --target='/www/thelounge.net/contentlounge/updateservice/documentation/code-referenzen/contentlounge' --title='ContentLounge - Technische Referenz' --defaultpackagename=ContentLounge --ignore=autotests --ignore='create.d' --ignore=contentlounge-api --ignore=pel --ignore=Rounded --ignore='global_class.phpmailer.php' --ignore='global_class.smtp.php' --ignore='orf_verify_smartcard.lib.php' --ignore='error_page_lounge.php' --ignore='error.php' --ignore='fwx_ffmpeg_testsuite.php'". Message: "\Content-Lounge-API" is not a valid Fqsen." ["exception" => InvalidArgumentException { …},"command" => "run --force --quiet --no-debug --cache-folder='/tmp/phpdoc-cache' --encoding=ISO-8859-1 --directory='/www/thelounge.net/contentlounge/updateservice/package' --target='/www/thelounge.net/contentlounge/updateservice/documentation/code-referenzen/contentlounge' --title='ContentLounge - Technische Referenz' --defaultpackagename=ContentLounge --ignore=autotests --ignore='create.d' --ignore=contentlounge-api --ignore=pel --ignore=Rounded --ignore='global_class.phpmailer.php' --ignore='global_class.smtp.php' --ignore='orf_verify_smartcard.lib.php' --ignore='error_page_lounge.php' --ignore='error.php' --ignore='fwx_ffmpeg_testsuite.php'","message" => ""\Content-Lounge-API" is not a valid Fqsen."]
15:00:18 ERROR [console] Error thrown while running command "run --force --quiet --no-debug --cache-folder='/tmp/phpdoc-cache' --encoding=ISO-8859-1 --directory='/www/thelounge.net/contentlounge/updateservice/package' --target='/www/thelounge.net/contentlounge/updateservice/documentation/code-referenzen/contentlounge' --title='ContentLounge - Technische Referenz' --defaultpackagename=ContentLounge --ignore=autotests --ignore='create.d' --ignore=contentlounge-api --ignore=pel --ignore=Rounded --ignore='global_class.phpmailer.php' --ignore='global_class.smtp.php' --ignore='orf_verify_smartcard.lib.php' --ignore='error_page_lounge.php' --ignore='error.php' --ignore='fwx_ffmpeg_testsuite.php'". Message: "\Content-Lounge-API" is not a valid Fqsen." ["exception" => InvalidArgumentException { …},"command" => "run --force --quiet --no-debug --cache-folder='/tmp/phpdoc-cache' --encoding=ISO-8859-1 --directory='/www/thelounge.net/contentlounge/updateservice/package' --target='/www/thelounge.net/contentlounge/updateservice/documentation/code-referenzen/contentlounge' --title='ContentLounge - Technische Referenz' --defaultpackagename=ContentLounge --ignore=autotests --ignore='create.d' --ignore=contentlounge-api --ignore=pel --ignore=Rounded --ignore='global_class.phpmailer.php' --ignore='global_class.smtp.php' --ignore='orf_verify_smartcard.lib.php' --ignore='error_page_lounge.php' --ignore='error.php' --ignore='fwx_ffmpeg_testsuite.php'","message" => ""\Content-Lounge-API" is not a valid Fqsen."]

In Fqsen.php line 51:

"\Content-Lounge-API" is not a valid Fqsen.

[jaapio]

This was another bug in v2. I understand that it is frustrating to get this information right now. But a package is equal to a namespace.

https://docs.phpdoc.org/latest/references/phpdoc/tags/package.html

A new version of our docblock reader is ready to be integrated which will make it more robust against invalid tag usages. So phpDocumentor can just continue it's job to read and process all files. but some of the information will be lost. Follow #2205 to be updated when it is done.

not that dramatically as phpdoc did with 2 as well as 3
Sure, we needed to this breaks because it was way to hard to build in all new php-features. And there have been added a lot of them since the first line of phpDocumentor was written. It is not that we are doing breaking changes just to annoy our users. But only because we are convinced that this was the right way to do so.

If you are not convinced that we are doing the right job, you might have a look at https://github.com/ApiGen/ApiGen which is an alternative to phpDocumentor.

[thelounge-zz]

This was another bug in v2. I understand that it is frustrating to get this information right now

for sure not - the @package docblock predates namespaces many years and i don't care about php namespaces at all because i avoid 3rd party code since 2002 like the devil a church

@package is meant to seperate project parts or projects within the folder tree of shared code and i won't rewrite 17 years of codebase working well without any namespace just because of phpdoc

you seriously can't call everything you damaged which was working in the past a bug that it has worked

[mvriel]

you seriously can't call everything you damaged which was working in the past a bug that it has worked

Again, I would like to ask you to restrain yourself in your communication style.

We are all for a better PHP world for everyone and as I explained before, we also need to make choices to serve as many users possible within the constraints that we have. So to make accusations is not helping anyone.

The only thing you achieve by using this tone is that I have less of a desire to invest the time and energy to look at what you are _actually_ trying to communicate and try to support this without making large changes or concessions towards other use-cases.

Although I cannot speak for Jaap, I cannot escape the feeling that he experiences this in a similar fashion and I empathize.

Having said that, I have looked at your reports above and found the following:

1. When using hyphens in an @package tag; the application fails. This is indeed not according to the specs put forth by phpDocumentor 1; I have made a fix on the master branch that will resolve this situation.

2. As for displaying the documentation for an application that uses @package as a basis for organisation instead of namespaces: it is true that the templates primarily look at a namespace based application as that is the majority of our users. Nonetheless, with phpDocumentor 3 we are building a new template as we are painfully aware of the limitations of the prior templates. While building this new template I can take your complaint into account and find a way to serve both styles of project organisation.

As Jaap mentioned, we are not releasing alpha's on a regular basis as we prefer to focus on fixing a lot of bugs and improving the QA pipeline. During the last alpha, we had to conclude that more work is needed and we would wait releasing a new alpha until we are confident that we found and solved most issues that _we_ can find.

At the same time, we understand the desire to try the latest version; for this reason we create and host a PHAR file with each build we do in the 'actions' tab. If you open a build there and check the upper right corner you can download a generated PHAR file from the 'artifacts' dropdown.

[thelounge-zz]

to make it short: my problem is that there is no single phpdoc in the meantime for years working with a recent PHP and i am shortly before make a 250.000 LOC codebase dating back to 2002 PHP 7.4 only and if phpdoc continues to be the showstopper i just send out a mail "phpdocs are gone, look at the soruce code which has pretty documentation all the years"

frankly i am ready for PHP 8.0 with and withourt jit/preloading at the moment and the 250.000 LOC codebaseis a one-man-show the past 17 years with no external dependenices (and no serious compat breaks because other than you i have to suck every break at my own instead just push it) serving hundrets of domains, admin-backends for all sort of services, deployment-code and tounsands of lines of testing-oce - so my understanding for the shape of phpdoc is very limited

there is a difference between refcatoring and breaking the API which cli is a part of and normally that is covered by writing proper test code

now you propose using config files - guess what - i used config files for phpdocs over a full decade until they got broken completly with incompatible changes

and no - i sulrey won't limit my developemt and coding style to whatever phpdoc thinks is coll now until it breaks in pieces a few months later with the next php minor which is nothing falling from heaven - you can test and fix stuff 6 months before a GA release

Just face the maount of jquery, jquery-ui and what not javascript frameworks for something like a documentation makes me puke - not talking about most of the tmneplates are horrible broken by no navigation and so on

namespaces are syntax, phpdoc comments are phpdoc comments - period

[mvriel]

We are volunteers who do not get paid, nor have the ability to work full time on this product. Trying to compare your paid business with a _free_ volunteer-run effort is demeaning.

I recommend that you take a breather and come back later. Perhaps then we can continue a constructive conversation.

[thelounge-zz]

We are volunteers who do not get paid

trust me - most of the stuff i am doing i don't get paid for, it's just my attitude to make things proper (and perfection is not reache dwhen you have no idea what to add, it's reached when you can't remove things - templates for phpdoc - congratulations - there your time get wasted, make one proper and working output instead dozens with different defects)

if you won't blow up everyting the way it's done you won't have that much problems
having jquery 1.4.2 and jquery 1.7.1 for something which shouldn't need jquery at all shows the mess

[redaxmedia]

@thelounge-zz What the hell is wrong with you? I watched this conversation for a while but now I got enough of your blaming... take a look at your freaking empty contribution chart and shut the fuck up!

[thelounge-zz]

@redaxmedia sorry for phpdoc beeing the only piece of php stuff i didn't write at my own from scratch and that's only because i personally don't need a html documentation for a codebase written by my own with autocompletion in any IDE using the phpdoc comments phpdoc itself can't handle in new versions

what's wrong with me?

probably that i don't break comatibility and code for nearly 20 years all the time and beeing deployable at every moment in time no matter what i touch because i have to suck all my breakage by eating my own dogfood

probably that i don't claim something working fine in the past was a bug and breaking it is fixing that bug

probably that i don't wite bloatet code losing control of later

and what's probably really wrong with me is that i expect to see real progress within two years without the "it's free, what did you do" strawman when i don't comment for more than a year and aceept it to be unuseable all the time

[asgrim]

@thelounge-zz hey there, perhaps take some time away from your computer for a bit and relax. Hope you're okay, because the way you're treating the maintainers of this project is really not okay. ❤️ to you all.

[mvriel]

@thelounge-zz Consider this to be an official warning: if you continue your insults and combative messages I am forced to block you from this organisation.

This type of interaction distracts us from working on phpDocumentor and causes unnecessary grief. Please keep in mind that being blocked from an organisation affects how you can interact with the repositories in that organisation as described here: https://help.github.com/en/github/building-a-strong-community/blocking-a-user-from-your-organization

[jpoesen]

@thelounge-zz, abusing the developers until morale improves is not the best strategy. I suggest taking a breath and reflecting on what you can do to help instead.

Suggestions include:

• Starting your conversation with an acknowledgement of the time and effort the maintainers continue to put into this project.
• Changing your tone to a respectful one. We're all just people here, doing our best.
• Providing constructive criticism, rather than abuse.
• Contributing code, documentation, constructive bug reports, or funds to help fix things.

If none of these things are an option, for whichever reason, feel free to not use this software. The _Free_ in FOSS does not mean you're free to abuse and demoralise people.

Please be a little kinder in 2020. Surely that's not such a big ask?

[thelounge-zz]

@jpoesen the only option is not to use it anyways because it simply don't work and what drives me nuts is no progress in over a year and then come out and call things working 15 years a bug and the fix is no longer support it

finally the @package means a namespace is a bad joke - @package predates the \namespace syntax of PHP 10 years

[jpoesen]

@thelounge-zz I'm genuinely sorry you feel that way. The beauty of the open source community lies in working together and helping each other. But that requires people to stand still for a moment and actually, genuinely, listen to each other.

You're frustrated because of the lack of progress and because of some technical choices and statements. Everyone here gets that. The maintainers even acknowledged their part and agree with you. Several times. They are saying "yes, you are right, we need help, feel free to help".

How about you turn your negative energy into positive energy and use the following template to respond:

_Hi folks. Thanks for your contributions so far. I can currently not use the software for the following reasons:

• [reason 1] [link to separate issue]
• [reason 2] [link to separate issue]
• [reason 3] [link to separate issue]

What can I do to help make these issues go away?_

You seem very passionate about this. I hope you'll decide to use your passion and drive this project forward. It's up to you though.

[mvriel]

At this point, I believe everything is said regarding this topic. I am locking this issue.

Should a future reader of this thread run into the same issue as mentioned above and require additional information or assistance, please open a new issue.