<?php
/**
* #file
*/
/**
* Implements hook_page_alter().
*/
function glue_page_alter(&$page) {
$page['content']['bartik.content']['content']['#markup'] = 'Hello Content!';
}
What wrong with this hook? It wont run (8.4.3). I've cleared the cache too
In Drupal 7, hook_page_alter was a convenient way to go when we needed to modify page elements that were added by other modules. Drupal 8 does away with this hook - hopefully for the better. To fill the void created by hook_page_alter’s dismissal, the following hooks have been introduced.
hook_page_attachments()
hook_page_attachments_alter()
hook_page_top()
hook_page_bottom()
hook_theme_suggestions_HOOK()
hook_theme_suggestions_HOOK_alter()
Source: https://cryptic.zone/blog/where-hook_page_alter-drupal-8
Related
I found, in eclipse,
/*
* Hello world, this is green.
*
*/
The comments will be green. However,
/**
* Hello moon, this is blue.
*
*/
If I use /**, it will become blue.
So why? Any difference?
While /* starts a regular multi-line comment, /** starts a multi-line comment supporting the javadoc tool, which generates HTML documentation from your comments.
This is an example from the documentation:
/**
* Returns an Image object that can then be painted on the screen.
* The url argument must specify an absolute {#link URL}. The name
* argument is a specifier that is relative to the url argument.
* <p>
* This method always returns immediately, whether or not the
* image exists. When this applet attempts to draw the image on
* the screen, the data will be loaded. The graphics primitives
* that draw the image will incrementally paint on the screen.
*
* #param url an absolute URL giving the base location of the image
* #param name the location of the image, relative to the url argument
* #return the image at the specified URL
* #see Image
*/
public Image getImage(URL url, String name) {
try {
return getImage(new URL(url, name));
} catch (MalformedURLException e) {
return null;
}
}
The Java API specification itself is an example of HTML documentation generated through javadoc.
Comments starting with /* are normal code comments. These are generally used on top of a code line to describe the logic.
Comments starting with /** are used for javadocs. These are used on top of methods and classes
/* is just a multiline comment.
/** is for Javadoc, which allow you to make a doc more readable for users.
Take a look
Javadoc
While the /** comment starter is for javadoc, technically they are actually the same from the compilers point of view. A comment is a comment is a comment. The important part here is that /** is /* with an extra asterisk added.
/* text */: The compiler ignores everything from /* to */
/** documentation */:
This indicates a documentation comment (doc comment, for short). The compiler ignores this kind of comment, just like it ignores comments that use /* and */. The JDK javadoc tool uses doc comments when preparing automatically generated documentation. For more information on javadoc, see the Java tool documentation
namespace Admin\Shell;
use Cake\Console\Shell;
class AdminAlertShell extends Shell{
...
...
}
Here 'Admin' is plugin, So I created this file inside the plugins folder structure.
File path : /plugins/Admin/src/Shell/AdminAlertShell.php
Tried to run this in CLI
bin/cake admin_alert
But an exception throws
Exception: Unknown command cake admin_alert. Run cake --help to get the list of valid commands. in [localpath/vendor/cakephp/cakephp/src/Console/CommandRunner.php, line 346]
It was working. But I don't know what happened to this. I had upgraded cakephp 3.5 to 3.7. But, I am not sure this caused the issue.
I just tracked down the source of the issue in my project.
Inside my plugin there was a file: src/Plugin.php
Inside this class there was the following lines of code:
/**
* #inheritDoc
*/
public function console(CommandCollection $commands): CommandCollection
{
// Add console commands here.
return $commands;
}
This was probably generated via bake.
I saw that the parent was not called. In the path is added in the parent.
Change this method to look like this:
/**
* #inheritDoc
*/
public function console(CommandCollection $commands): CommandCollection
{
// Add console commands here.
$commands = parent::console($commands);
return $commands;
}
Now the parent is called and the path is added to the command collection.
As a side note I also see the middleware is not calling its parent.
Think it would be a good idea to fix that one aswell.
As an alternative you can just clear out the class and all defaults should be used.
Hope this saves someone the hours it cost me to figure this one out.
I'm having trouble with the WebStorm code analysis tool.
In a node express server I send an object:
var configSummary = {
'siteDirs': siteDirs,
etc...
};
res.status(200).send(configSummary);
In a web app I use jQuery to ask the express server to send back a JSON object:
$.getJSON('/makers/config', function(configSummary) {
configSummary.siteDirs.forEach(etc...
})
The code runs without error, but the WebStorm code analysis annotator for my web app quite reasonably complains that configSummary.siteDirs is an unresolved variable. I know how to suppress the error in the editor with a comment, but I don't like that solution. Instead, I would like to teach WebStorm about the configSummary object or tell it to ignore that "type" in the client side JavaScript file. How can I do that?
In cases when the actual data is only known at runtime (for example, when data is a value set through ajax call), it can't re resolved during static analysis, thus the error.
It's not possible to suppress analysis for specific error type - you can only suppress it for statement using comments. But you can let the IDE know what your data looks like.
Possible solution using JSDoc annotations:
/**
* #typedef {Object} configSummary
* #property {Object} siteDirs
*/
...
$.getJSON('/makers/config', function (/** configSummary */ configSummary) {
configSummary.siteDirs.forEach(...)
})
See also https://youtrack.jetbrains.com/issue/WEB-17419#comment=27-1058451, http://devnet.jetbrains.com/message/5504337#5504337 for other possible workarounds.
You can open any of .js library files from plugins/JavaScriptLanguage/lib/JavaScriptLanguage.jar!/com/intellij/lang/javascript/index/predefined/ to see what stub definitions look like
I intend to include some documented C++ classes (let say AClass) within a Doxygen group (let say GROUP_C), while that group is into another one (let say GROUP_B), and that second group into another, base one (let say GROUP_A). Like this:
/** \addtogroup GROUP_A */
/** #{ */
/** \defgroup GROUP_B */
/** #{ */
/** \defgroup GROUP_C */
/** #{ */
/// Comment
class AClass
{
};
/** #} */
/** #} */
/** #} */
I'm trying to get a clean and logical documentation for that situation, but, as simple as I see it, I have not been able to found anything more specific than the Doxygen official documentation, where nothing is said about any cyclical grouping problems. However, just doxygen-ing the simple code above, such problems occur:
warning: Refusing to add group GROUP_C to group GROUP_B, since the latter is already a subgroup of the former
I also get strange breadcrumbs indications of the generated module under the AClass documentation:
Does anybody know what am I understanding wrong in the nesting-group system of Doxygen?
Thanks in advance!
This solution has been working for me for many years since old versions of Doxygen:
/** \defgroup GROUP_A My top-level group description
*
* Put here a longer description.
*
**/
/** #addtogroup GROUP_B My group B description
* \ingroup GROUP_A
* #{ */
// classes, etc.
/** #} */
/** #addtogroup GROUP_C My group C description
* \ingroup GROUP_B
* #{ */
// classes, etc.
/** #} */
Unfortunately your given example works as expected on doxygen-1.8.8 and on latest master git branch. The warning does not appear.
Is it possible you are including other source files (than the presented example code) into your test run and that other files contain conflicting \defgroup or \addgroup statements that cause the circles in the group structure?
Regarding that "GROUP_A" doubling line below "AClass Class Reference" - I guess that is simply a doxygen bug.
In order to avoid the Slowly Changing Dimension problem (in short: I want to keep my order data even if a user gets deleted from the system), I thought about hijacking the delete event and instead setting an invalid flag on the record.
I know of the softdeletable filter from StofDoctrineExtensionsBundle but I'm unsure if this will cascade to child objects.
Is this a common/good practice/idea and do this with the following lifecycle callback?:
/
/**
* #ORM\PreRemove
*/
public function makeInvalid() {
$this->enddate = new \DateTime(); // set the end of validity property to now
cascadeToRelatedObjects(); // i.e. make sure all 'child' objects also change validity
somehowContinueTheOperation(); // i.e. do not cause an Error of sorts
}
or should I, rather, change the functionality of the delete button on the form and assign an update function to it which does the above?
In fact, using the softdeleteable from DoctrineExtensions is the way to go. It even cascades fine if you set the cascade={"remove"} option correctly on the property of your owning object (generally speaking, the one with OneToMany).
Correct me if I'm wrong, but I don't think you need to set onDelete="CASCADE", as this is a function executed by the database, which is unaware of the requirement to soft-delete, so it won't soft-delete any children.
The easiest way for me to get this extension, was to installing StofDoctrineExtensionsBundle with the command composer require StofDoctrineExtensionsBundle and configuring it in config.yml, you can use it as described below. Soft-deleting an instance of Device will then also soft-delete its dependent Parts.
For restoring them you'd probably have to write a function or something.
use Gedmo\Mapping\Annotation as Gedmo;
/**
* ...
* #Gedmo\SoftDeleteable(fieldName="deletedAt", timeAware=false)
*/
class Device {
/**
* #ORM\Column(name="deletedAt", type="datetime", nullable=true)
*/
private $deletedAt;
/**
* #ORM\OneToMany(targetEntity="Part", mappedBy="device", cascade={"persist","remove"})
*/
private $parts;
}