I'm using the tool from phpdoc.org and i'm stuck when I have a PHP file such as header.inc.php with only HTML inside.
<?php
/**
* Header content
*
* #author My name
*
* #since 1.0.0
*/
?>
<!DOCTYPE html>
<html lang="fr" class="no-js">
<head>
...
I get an error in my phpdoc "No page-level DocBlock was found in file...". I googled it but I didnt find any user with my case.
How to fix that error? Any tips are welcome.
Thank's!
Regards
I just ran across this posting and though it's older, I thought I would add my two cents. While sylouuu is correct about placing a namespace directly after the your intended page-level DocBlock, I believe that it is now required to place the '#package' tag in the DocBlock. There is some caution here when dealing with logical versus hierarchical 'packages'. This behavior is basically dependent upon which version of PHPDocumentor you are using.
From: http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_elements.pkg.html
"In phpDocumentor version 1.2.2, a Page-level DocBlock is the first DocBlock in a file if it contains a #package tag."
And at https://github.com/phpDocumentor/phpDocumentor2/issues/910 it can be read that as recently as a month ago, the issue of page-level DocBlocks in files with no PHP code/nodes is still being worked. Thus, as sylouuu stated about adding a namespace, once you do this, you have an documentable element and your problem should be resolved. Additionally, since most likely no documentation for the page will be created without having a node present, this allows your html-only file to have its documentation created.
Hope it helps!
dw
Ok anwser found: https://github.com/phpDocumentor/phpDocumentor2/issues/695
TL;DR: At the moment, it's not fixed, just ignore theses warnings.
Related
Anyway to examine the final XML structure magento comes up with after parsing & combining all the different XML files?
There is nothing of that sort which turned up on searching on the internet and I think for someone like me, magento layouts were a bit too much in the beginning & I would try to do everything on the code side.
Another thing which will help in picking up the name of different nodes that we can use, right away from the final XML structure.
Never ran into this but I believe we will have a better picture of what's overriding what.
The following will get you the merged configuration from app/etc/*.xml, app/etc/modules/*.xml, as well as each (active) module's config.xml file; when retrieving the config though there is no indication of what was overwritten, as the merges happen as each config file is being parsed:
Mage::getConfig()->getNode()->asNiceXml(); // or asXML() | asArray() | etc.
However, you seem to be asking about how the application makes use of this information. This is a function of application design.
Also, you mention "all of the different XML files." It's worth noting that these are not maintained in one massive object instance. For example, layout XML is accessed using the layout update object Mage_Core_Model_Layout_Update and can be accessed meaningfully after it's been loaded and manipulated for a given rendering scope (e.g. loadLayout() in a controller action):
Mage::app()->getLayout()->getUpdate()->asString(); // or asSimplexml() or asArray()
Yes - Commercebug. As well as a whole load of other useful features, you can also view the entire XML structure that Magento has produced.
http://store.pulsestorm.net/products/commerce-bug-2
I believe the following will output the XML: echo Mage::getConfig()->getXmlString();
You can create a script with something like this:
header("Content-Type:text/xml");
require_once '../app/Mage.php';
Mage::app();
echo Mage::getConfig()->getXmlString();
based on answer from benmarks I did
echo "<pre>".htmlspecialchars(Mage::getConfig()->getNode()->asNiceXml())."</pre>";
If you want for example to see the blocks configuration in Magento 1 you can put this in a file, place the file at the root of the site and navigate to it in a browser:
<?php
include("app/Mage.php");
Mage::app();
//just see blocks...
echo "<pre>".htmlspecialchars(Mage::getConfig()->getNode()->global->blocks->asNiceXml())."</pre>";
die();
We have a page-level docblock like the following:
/**
* Functions for the processing, displaying, and searching of listings
*
* #package ListingFunctions
*
*/
The rest of the file has functions with their own docblocks. But my team and I can't find this comment anywhere in the generated HTML output. Is there some configuration or command-line stuff we need to turn on?
Using phpDocumentor 1.x, that "short description" piece should be the main description heading on the webpage for that given file. It won't appear on those functions in that file... just on the file itself. This is core behavior, that cannot be modified by runtime settings.
Some modules have a <request><direct_front_name>...</direct_front_name></request> in their module config, for example xmlconnect and api. What is this tag for?
What I think it is for:
xmlconnect and api are both used as direct entry points for the site (as opposed normal modules which are reached mostly from within the site). So in combination with the option to use store codes in your store urls you can specify a direct_front_end tag to make the store code not necessary for those modules. This way there is no 404 when calling them without a store code.
(Kind of answered it myself, but couldn't find any information about it online. Might be of use to others. And maybe anyone has something to add.)
You're totally right. And the php DOC clearly tells so :
Mage_Core_Controller_Request_Http::isDirectAccessFrontendName() :
/**
* Check if code declared as direct access frontend name
* this mean what this url can be used without store code
*
* #param string $code
* #return bool
*/
public function isDirectAccessFrontendName($code)
In CodeIgniter Project, I've normally use following commands to execute sql.
$res = $this->db->select('*')
->from('customer')
->where('customer.id', $id)
->get();
But unfortunatly my PHP Storm(5.0) didn't support multiple autocomplete(I don't know how to say this)
For example in netbeans If I typed
$res = $this->db->select('*')->
It will auto pop up the rest of the function. But In PHPStorm It didn't wokring.
Its working first level auto complete only.
download https://github.com/topdown/phpStorm-CC-Helpers/releases
Mark as Plain Text
/system/core/Controller.php
/system/core/Model.php
/system/database/DB_active_rec.php
Then Extract the downloaded archive, copy it to your project root
That's all
Mifas links do the same too though
Answering to a very old but still pertinent question -
I found a better solution herein - http://validwebs.com/346/code-completion-for-codeigniter-in-phpstorm/ and coincidentally it is from the same author/project owner Jeff Behnke.
Quoting from therein which should be read in continuation of the answer by Sabir -
Mark as Plain Text
/system/core/Controller.php
/system/core/Model.php
/system/database/DB_active_rec.php
Marking those files as plain text stops phpStorm from indexing them as
sources.
I consider the solution in the link better because it explains the rationale behind the steps performed.
It additionally explains how we can achieve code completion in views and fix for undefined vars.
Quoting once again from the original source for easy reference and preservation herein :
Code Completion in Views and fixing undefined vars.
Example controller code.
public function index()
{
// Example view vars
$data['test'] = 'Testing vars in CodeIgniter! This is from $data["test"].';
$this->load->view('welcome_message', $data);
}
We added a data array to the view the CI way. Each index in the array
is another variable.
The view…
In phpStorm $test will be highlighted as an undefined var. To fix this
we use phpDoc annotations.
<p style="font-weight: bold;">
<?php
/**
* $data array holds the $test value
*
* #see Welcome::index()
* #var Welcome $test
*/
echo $test;
?>
</p>
Documenting this way not only fixes the phpStorm error/warning but
also gives us documentation popup for $test. Also the #see will link
to the location it was created, in this case index method in the
Welcome class.
The var is now defined and shows it is.
Ctrl+ Click on this method link will bring you right to the method
where $test is defined.
Herein are a few discoveries of my own while adding customisations to my project:
If you want your custom application libraries from CI to be available for auto-completion as well then there are these 2 scenarios which may be helpful :
1. For custom extended libraries such as MY_Upload extending the CI_Upload class
Replace #property CI_Upload $upload with #property MY_Upload $upload in CI_phpstorm.php
This shall make all the class variable and function names of MY_Upload available for auto-completion in addition to that of CI_Upload.
2. For completely custom libraries written from scratch within the CI application -
For e.g. to enable auto-completion from Custom_Library.php residing in the application/libraries folder, you need to add to the php doc in CI_phpstorm.php #property Custom_Library $custom_library
When I turn on cache in Magento, I get the following exception:
Serialization of 'Mage_Core_Model_Layout_Element' is not allowed
Exception occurs in app/code/core/Mage/Page/Block/Template/Links.php, on line:
return parent::getCacheKeyInfo() + array(
'links' => base64_encode(serialize($links)),
'name' => $this->getNameInLayout()
)
I am using Magento Enterprise 1.10 and PHP 5.3.
Can anyone tell me what the problem is?
You shouldn't have an empty after_text or before_text tags in your layout file. If you don't need it, just delete the tag at all.
If it will not help, dump the $links variable before the 150th line in the app/code/core/Mage/Page/Block/Template/Links.php file, and you will see an array with arrays inside it. All of keys and values should be strings or integers, not objects. The key of array value which is an object will tell you which tag to delete from the layout file.
Awesome #vsushkov.
I used:
try{
serialize($links);
} catch(Exception $e){
Mage::log($links);
die;
}
to find out exact layout where we had those empty tags and after removing those empty tags, it fixed the issue and then removed above code :-)
Saw this issue on a clients site. None of the solutions above worked for me. After much googling of the error, it seems to be related to JM or JoomlArt themes/extensions.
The code is extremely poorly written. For example some of the things you will find in these themes include:
Declaring php classes inside templates,
Setting global variables inside templates,
Setting data into superglobals from templates,
Providing a translation file, yet not wrapping most text strings in template in the translate function
I found 1 response from their support staff essentially suggesting to turn off error reporting to fix the issue.
I found my problem in app/design/frontend/default/jm_adamite/template/catalog/navigation/tops.phtml
There was a line setting $this into $_SESSION. I commented it out and the error went away. Nothing else appeared broken. A grep for that variable being used anywhere else had 0 results. If you have one of these JM extensions installed or use one of their themes, I would suspect that first
Good luck
This problem happened to me when trying to serialize categories after calling the getCategoryUrl function after digging i found out that that set _urlModel object which cannot be serialized as it contains Mage_Core_Model_Layout_Element so before serializing the object check if it has that _urlModel property