<?php
class Hello
{
public function hello()
{
return "";
}
}
I have function and I need to give comments and write documents for the same, like #param, #return.
How can I do that?
I am very new to PhpStorm.
What you are asking about is called PHPDoc: PSR-5: PHPDoc.
1) Place the caret before the required code construct (class, method, function, and so on), type the opening block comment /**, and press Enter.
2) In the editor context menu, select Generate | Generate PHPDoc blocks and choose the code construct to generate PHPDoc comments for.
3) Press Alt+Insert, then select Generate PHPDoc blocks, and choose the code construct to
generate PHPDoc comments for.
You can check this link for more info.: https://www.jetbrains.com/help/phpstorm/phpdoc-comments.html
Related
Hello guys I'm new to MediaWiki and trying to build my own extension. Using this extension I'm trying to show some content blow page heading but only to a page specific to a category.
For that, I'm using two hooks:
onArticleViewHeader ( To add my HTML content below the page heading)
onOutputPageMakeCategoryLinks (To get all the category of page being loaded)
From the first hook, I'm able to show my content using the following code:
public static function onArticleViewHeader( &$article, &$outputDone, &$pcache ) {
$article->getContext()->getOutput()->addHTML("Printed from a hook");
}
The above code prints the HTML below every page heading but I want to load HTML only to a specific page category. So for that, I'm trying to load the category and I'm just trying to call my first hook only if the category gets caught.
public static function onOutputPageMakeCategoryLinks( &$out, $categories, &$links ) {
foreach($categories as $category){
if($category=="my_page_category"){
MyExtentionClass::onArticleViewHeader();
}
}
}
I know I'm calling the hook in a bad manner which is not correct. But I just wanted to call my 1st hook 'onArticleViewHeader' from inside of my 2nd hook so that I can print my HTML only to a page with a specific category.
Just use $article->getPage()->getCategories() in the header hook.
Haven't really got the exact solution of the question I asked but has got the way out to solve the problem I have been facing.
I just tried getting the current categories in the "onArticleViewHeader" itself by using some of MediaWiki's global variables.
global $wgOut;
$title = Title::newFromText( $wgOut->getPageTitle() );
$categories = $title->getParentCategories();
if(isset($categories['Category:my_cat_name']){
//formed my logic here
}
This might help some other people facing this kind of issue.
The register sidebar wordpress function has one parameter called "before_widget - HTML to place before every widget(default:'<li id="%1$s" class="widget %2$s">') "
At the end it adds
"Note: uses sprintf for variable substitution"(wp codex).
I test it on a site, and depending on the widget that I supply/activate it takes the name of the widget, an id plus a class e.g. for a search box it will became id="search-2" class="widget widget_search"
Where is this sprintf and where are these variables? Where is this function that manipulates this parameter? I checked the register_sidebar() function in wp-includes/widgets.php file but I could not find it.
sprintf and the variables you are searching for is present in wp-includes/widgets.php itself. Please refer the function dynamic_sidebar present in wp-includes/widgets.php.
The exact line of code you are looking for is given below:
$params[0]['before_widget'] = sprintf($params[0]['before_widget'], $id, $classname_);
How can I add custom input names to gravity forms? I need to submit a form to a third party service that requires very specific form names.
My current idea is to write a bit of jQuery to dynamically rename everything when the page loads. Obviously this isn't ideal.
Gravity Forms: http://www.gravityforms.com/
After contacting the makers of Gravity Forms, it sounds like they don't support custom input names. As a workaround, I wrote a bit of jQuery to rename inputs with the correct form names. For example:
$("input#input_1_1").attr("name","first_name");
Just put some code in functions.php and fill out the form which will then email you with a list of the id names, they are the same names that you can fine using developer tools etc. This was just faster for me. Then change the code to have it post via curl with different input names.
This uses php so it's on the server to handle. That way you don't have to worry about people with JS disabled in their browser.
http://0to5.com/gravity-forms-submitting-forms-to-3rd-party-applications/
Add a new field (HTML field). In content settings of this field add this javascript with script tags
Non-jquery solution:
document.getElementById("input_14_4").setAttribute("name", "email");
Another solution i found here
https://docs.gravityforms.com/gform_field_content/
add_filter( 'gform_field_content', function ( $field_content, $field , $value, $lead_id, $form_id) {
if ( $form['id'] != 14 ) {
//not the form whose tag you want to change, return the unchanged tag
return $field_content;
}
if ( $field->id == 3 ) {
return preg_replace( "|name='(.*?)'|", "name='email'", $field_content );
}
return $field_content;
}, 10, 5 );
I need to change the function that dictates the behavior of my Search form. I want the text to be "GO" instead of "Search" and the input type to be search instead of text.
Now, I already done that by editing the search.module, but is there a more convenient way? I want the theme to be 1 package deal and ready to go, not to have to edit other files from the Drupal installation.
It is for Drupal v.7.16
Thank you!
In your theme's template.php you can override any part of the search form by implement MYTHEME_form_alter.
For your example, it might look something like this:
function MYTHEME_form_alter(&$form, &$form_state, $form_id) {
if ($form_id == 'search_block_form') {
// Change form submit text
$form['actions']['submit']['#value'] = t('GO!');
// Change type to 'search'
$form['search_block_form']['#type'] = 'search';
}
}
For more background information about Tanis' solution, see the API documentation for hook_form_alter() and hook_form_FORM_ID_alter().
I need to have a place to put some common functions that various view scripts will use such as creating some html by passing it a variable. I know about using helpers, but I want to be able to put many functions inside it not just one helper for each function.
Is it a plugin that I need to create?
thanks
A view helper is definitively the way to go. You can group a collection of similar or related functions using a simple design pattern for your view helper:
class App_View_Helper_Example extends Zend_View_Helper_Abstract
{
/**
* #param mixed|null $var
* #return App_View_Helper_Example
*/
public function example($var = null)
{
if ($var === null) {
return $this;
}
return $this->function1($var); // shortcut to method most used
}
public function function1($var)
{
return $this->view->escape($var);
}
public function function2($var1, $var2)
{
return $this->view->escape(sprintf('%s: %d', $var1, $var2));
}
// and so on...
}
This allows you to call your helper methods in your view like this:
$this->example($var);
$this->example()->function1($var);
$this->example()->function2($var1, $var2);
I used this approach for a Google Static Map helper which provides a centered()-method to display a map centered at a given location and a byMarkers()-method that displays a static map automatically centered and zoomed around a list of given markers.
The only problem you may encounter is keeping a state in your helper across different view scripts (e.g. when using layouts or partials) as the helper will be reconstructed with every single view script. To store state across these boundaries you'll have to resort to Zend_Registry or some static member field.
Hm, 'sounds a bit smelly'. What kind of functions would these be? If your design is ok, you shouldn't have a need for this kind of dustbin class. If it is really all about view then you should create view helpers, view partials or partial loops!
Sounds like what you want is the partial helper
If you don't want to use helpers (including the partial helper) you might as well just create some global functions, stick them in some file, and include it from your bootstrap file.
If you don't want a 'bunch of helpers' (which isnt really all that bad, as other posters have suggested), you can extend Zend_View, add the member methods, then set the Viewrenderer to your extended View.
http://framework.zend.com/manual/en/zend.controller.actionhelpers.html#zend.controller.actionhelpers.viewrenderer
Thank you all for the suggestions.
I discovered that you can use a view helper (like Stefan said) to store more functions by just returning $this from it like :
class Zend_View_Helper_FormVars
{
public function formVars(){
return $this;
}
public function openFormFieldGroup($name=''){
$html='';
$html.='<div id="formFldGrpWrapper">';
$html.='<div id="formFldGrpName"><b>'.$name.'</b></div>';
return $html;
}
}
Now in my view script I can use it like this:
$formVars=$this->formVars();
$html.=$formVars->openFormFieldGroup('General');
But I'm also interested in what Justin stated that I can have a common extended view helper?
That all my views or controllers can access for doing repetative tasks like some html divs/styles, etc.... How would I go about getting that set up?
thanks.
But I'm also interested in what Justin stated that I can have a common extended view helper? That all my views or controllers can access for doing repetative tasks like some html divs/styles, etc.... How would I go about getting that set up?
In the answers you ask this additional question. My answer deals with that too.
First you need to ask yourselves why you want to have multiple helper functions in one class
One reason is that you saves you extra classes and file includes. How could you do so?
If they are related you can put them into one view helper. But don't do things like
$this->htmlWrapper()->wrapParapgraph()->wrapContentBox()
->translateFromTo('NL', 'EN');
translateFromTo(…) has nothing to with html-wrapping.
If you want to optimize your includes, you can put you common helper code into a derived View-class:
class MyView extends Zend_View
{
function wrapParagraph() {}
function otherFunction() {}
}
This option is also mentioned in the zend framework guide as a means of optimization.
Please note that view helper reusability isn't affected by the choice to create view helpers as separate classes. You automatically get access to the current view oject if your helper extends Zend_View_Helper_Abstract.
class My_View_Helper extends Zend_View_Helper_Abstract
{
function wrapParagraph($content) {
// do something …
return $this->someOtherViewHelper();
}
}
Further you wrote
$formVars=$this->formVars();
This doesn't make sense actualy, since Zend_View registers only one view helper per view isntance.
$formVars=$this->formVars();
$formVars->doOneThing();
$formVars->doSecondThing();
is equivalent to
$this->formVars()->doOneThing();
$this->formVars()->doSecondThing();
The Singleton aspect has a severe impact on the way you design view helpers as you see.