@See tag not working correctly (namespace paths are lowercase), causing a 404, page not found

[wilson212]

As the description says, when using the @see tag on another namespaced class/method, the namespace paths are lowercase in the link (example: system.core.Database.html#%5CCore%5CDatabase::Connect() ).

My Doc Block:

/**

• PDO extension driver *
• This class is returned from the Database::Connect() method
• @see \Core\Database::Connect() *
• @author Steven Wilson
• @package Database
• @file system/core/database/Driver.php */

Edit: i seem to notice its adding "system." as part of the url. When i change the path to the system folder itself (since there is no system namespace), the links work again. Basically, the anchor link is linking the filepath to the class, rather then the namespace.

[mvriel]

I am afraid this is a known issue at the moment and needs to be quickly resolved. The problem is caused because the responsive and previous templates use a different URL scheme. The behaviour responsible for resolving the links still uses the old one.

We are working on implementing a routing mechanism so that templates may have their own routes. This in turn will offer template writers the flexibility to do so

[mvriel]

This issue is also reported in the phpDocumentor repository: https://github.com/phpDocumentor/phpDocumentor2/issues/640

[eggmatters]

I am getting a 404 when linking to a static method in another class. I have a property annotated with the @see tag: My Doc Bloc:

/**
     * @var int addressId credit_card.address_id column in database table. 
     * @see Address::getAddressByAddressId()
     */

And the corresponding doc bloc linked by the above:

    /**
     * Address::getAddressByAddressId()
     * 
     * <p>Static method constructs and returns an Address object by address id passed in
     * address id will be the corresponding address field in the database.</p>
     * <p>Method failure will return an errors array. Validate by:</p>
     * <code>
     * some code here
     * </code>
     * 
     * @param int $addressId addressId searched for
     * @param string $type address type passed in
     * @return array|Address Either an array key value pair ($arr[key], $arr[value]) on failure
     * or an Address object on success.
     */
public static function getAddressByAddressId($addressId, $type) {
...
}

When I generate the docs, The link issues a 404:

can't find the file at /home/dev_environment/php_docs/classes /class.Address.html#\Address::getAddressByAddressId().

There is no class.Address.html in my classes directory, just an Address.html file. The php file itself is "class.Address.php" as that is common php class file naming convention.

Inspecting the Address.html doesn't seem to yield anything:

<a id="method_getAddressByAddressId"></a><div class="element clickable method public method_getAddressByAddressId" data-toggle="collapse" data-target=".method_getAddressByAddressId .collapse">

And the structure.xml for the link is

<method final="false" abstract="false" static="true" visibility="public" namespace="global" line="206" package="myPackage">
        <name>getAddressByAddressId</name>
        <full_name>getAddressByAddressId</full_name>
        <docblock line="186">
          <description>Address::getAddressByAddressId()</description>
          <long-description>&lt;p&gt;Static method constructs and returns an Address object by address id passed in</long-description>
         param tags etc.
      </method>

We do not implicitly name any namespaces in this application. The documentor assigns the "global" namespace to my documentation, Utilizing:

@see global\Address::getAddressByAddressId()

Does not issue the 404 but simply links to the top of same document it is linking from.

I am not seeing anything that should be amiss with my descriptions here.

BTW: Here is a workaround kludge:

cp Address.html class.Address.html

Where am I causing the parser to think that this file should exist? Why would it try to link to a non-existent file anyways? Shouldn't this be a defacto functionality like javadoc? Didn't previous versions encapsulate this? I mean, it's a great effort and the output sure looks slick but a bug like this seems to be somewhat of a non-starter.

[mvriel]

This serms to be a bug with generating the routes for those tags. Next version will contain a routing component that will enable templates to properly enforce routes. My apologies for the inconvenience