Hi I dont fully understand to hooks in prestashop 1.0.6.9.
For example where i found the code which is executed when
Hook::exec('actionProductSave', array('id_product' => $this->id));
from Product class in add method
Hooks can be used by modules. There are two types of hooks:
action: These hooks are triggered by specific events that take place in PrestaShop
display: These hooks result in something being displayed, either in the front-end or the back-end
More info about hooks:
Hooks in PrestaShop 1.5
Understanding and using hooks
You can check which modules use the actionProductSave hook in PrestaShop back-office -> Modules -> Positions. None of the core modules use it.
Related
I'm new to this frontend world, I have some knowledge on React and GraphQL and that's why I've decided to try and implement a test blog with Gatsby, as it seems pretty popular and easy to use.
I also wanted to get my hands into Material UI so I'm using this Gatsby starter : https://www.gatsbyjs.org/starters/Vagr9K/gatsby-material-starter
This starter seems to have included the integration with Netlify CMS, so I wanted to change that and start using Strapi CMS, so I can have the content there.
Any idea on how to do this?
There's a lot of stuff in your question, I'll try to answer it step by step if not, please let me know if you need more details of how to create pages, etc and I will update my answer to add more details if needed.
If you want to change your source from Netlify to Strapi you need to set it up in your gatsby-config.js, replacing gatsby-plugin-netlify-cms plugin for something like that:
{
resolve: `gatsby-source-strapi`,
options: {
apiURL: `http://localhost:1337`,
queryLimit: 1000, // Default to 100
contentTypes: [`article`, `user`],
//If using single types place them in this array.
singleTypes: [`home-page`, `contact`],
// Possibility to login with a strapi user, when content types are not publically available (optional).
loginData: {
identifier: "",
password: "",
},
},
},
Note that you'll have to install your desired plugins and remove the unnecessary in order to reduce the bundle package and improve performance when using starters.
The next step is to create pages from your source CMS (articles, posts, pages, etc) using GraphQL. Maybe this blog helps you. But as a short summary, you need to create queries in your gatsby-node.js to retrieve data from Strapi CMS and create pages using Gatsby's API.
The idea is the same as from your starters, however, instead of using gatsby-source-filesystem and using allMarkdownRemark in your page creation, you will use the object provided by Strapi CMS. You can check the queries and the available objects using gatsby develop and entering to localhost:8000/___graphql.
Keep in mind that you will always query static data (i.e: pre-downloaded data) from your multiple sources so when you run the develop command, the data is downloaded and accessible via GraphQL.
You can check for further information in its starter repository.
for my current site I have a content type that stores a user in an entity reference field. I want to allow the user referenced in this field to edit the data of that node. In drupal7 I would do that with a node_access hook - which I am not getting to work in drupal8.
Here is a demo code of my hook - for testing purposes I want to forbid everything. However it is never called, and no - I am not logged in as user1. Also reseted cache, uninstalled and installed the module again and rebuilt the permissions - nothing seems to make this hook work.
function mymodule_node_access(\Drupal\node\NodeInterface $node, $op, \Drupal\Core\Session\AccountInterface $account) {
$access = new AccessResultForbidden();
return $access;
}
My question is why is this hook never called - and if there is now with drupal 8 a better way to do so?
Any help will be appreciated.
Best regards,
Rambazamba
This hook is never called for user 1, since he bypasses every access control.
Try testing anonymously or as another role.
Try the following command. The tool 'drupal console' is required.
drupal node:access:rebuild
I have a working ordinary Hapi application that I'm planning to migrate to Swagger. I installed swagger-node using the official instructions, and chose Hapi when executing 'swagger project create'. However, I'm now confused because there seem to be several libraries for integrating swagger-node and hapi:
hapi-swagger: the most popular one
hapi-swaggered: somewhat popular
swagger-hapi: unpopular and not that active but used by the official Swagger Node.js library (i.e. swagger-node) as default for Hapi projects
I though swagger-hapi was the "official" approach, until I tried to find information on how do various configurations on Hapi routes (e.g. authorization, scoping, etc.). It seems also that the approaches are fundamentally different, swagger-hapi taking Swagger definition as input and generating the routes automatically, whereas hapi-swagger and hapi-swaggered seem to have similar approach with each other by only generating Swagger API documentation from plain old Hapi route definitions.
Considering the amount of contributors and the number of downloads, hapi-swagger seems to be the way to go, but I'm unsure on how to proceed. Is there an "official" Swagger way to set up Hapi, and if there is, how do I set up authentication (preferably by using hapi-auth-jwt2, or other similar JWT solution) and authorization?
EDIT: I also found swaggerize-hapi, which seems to be maintained by PayPal's open source kraken.js team, which indicates that it might have some kind of corporate backing (always a good thing). swaggerize-hapi seems to be very similar to hapi-swagger, although the latter seems to provide more out-of-the-box functionality (mainly Swagger Editor).
Edit: Point 3. from your question and understanding what swagger-hapi actually does is very important. It does not directly serves the swagger-ui html. It is not intended to, but it is enabling the whole swagger idea (which the other projects in points 1. and 2. are actually a bit reversing). Please see below.
It turns out that when you are using swagger-node and swagger-hapi you do not need all the rest of the packages you mentioned, except for using swagger-ui directly (which is used by all the others anyways - they are wrapping it in their dependencies)
I want to share my understanding so far in this hapi/swagger puzzle, hope that these 8 hours that I spent can help others as well.
Libraries like hapi-swaggered, hapi-swaggered-ui, also hapi-swagger - All of them follow the same approach - that might be described like that:
You document your API while you are defining your routes
They are somewhat sitting aside from the main idea of swagger-node and the boilerplate hello_world project created with swagger-cli, which you mentioned that you use.
While swagger-node and swagger-hapi (NOTE that its different from hapi-swagger) are saying:
You define all your API documentation and routes **in a single centralized place - swagger.yaml**
and then you just focus on writing controller logic. The boilerplate project provided with swagger-cli is already exposing this centralized place swagger.yaml as json thru the /swagger endpoint.
Now, because the swagger-ui project which all the above packages are making use of for showing the UI, is just a bunch of static html - in order to use it, you have two options:
1) to self host this static html from within your app
2) to host it on a separate web app or even load the index.html directly from file system.
In both cases you just need to feed the swagger-ui with your swagger json - which as said above is already exposed by the /swagger endpoint.
The only caveat if you chose option 2) is that you need to enable cors for that end point which happened to be very easy. Just change your default.yaml, to also make use of the cors bagpipe. Please see this thread for how to do this.
As #Kitanotori said above, I also don't see the point of documenting the code programmatically. The idea of just describing everything in one place and making both the code and the documentation engine to understand it, is great.
We have used Inert, Vision, hapi-swagger.
server.ts
import * as Inert from '#hapi/inert';
import * as Vision from '#hapi/vision';
import Swagger from './plugins/swagger';
...
...
// hapi server setup
...
const plugins: any[] = [Inert, Vision, Swagger];
await server.register(plugins);
...
// other setup
./plugins/swagger
import * as HapiSwagger from 'hapi-swagger';
import * as Package from '../../package.json';
const swaggerOptions: HapiSwagger.RegisterOptions = {
info: {
title: 'Some title',
version: Package.version
}
};
export default {
plugin: HapiSwagger,
options: swaggerOptions
};
We are using Inert, Vision and hapi-swagger to build and host swagger documentation.
We load those plugins in exactly this order, do not configure Inert or Vision and only set basic properties like title in the hapi-swagger config.
According to this closed issue in sails:
https://github.com/balderdashy/sails/issues/835
CRUD Blueprint Overrides
"absolutely, this is coming in v0.10"
I'd like to modify the blueprints in my sailsjs service to allow named roots (consuming in ember).
Currently I'm having to customize every controller I create with actions that are largely duplicates of what is already in the blueprints.
I suspect that I can move this code out of my controllers now and into a blueprints override area, but I'm not clear on where to put that code.
Any examples or even just a pointer to the relevant code in sails the .10 repo would be greatly appreciated.
Update
In order to override blueprints in Sails 1.0 in the manner described below, you must first install the "custom blueprints" plugin for your project (npm install sails-hook-custom-blueprints).
To override blueprints in Sails v0.10, you create an api/blueprints folder and add your blueprint files (e.g. find.js, create.js, etc.) within. You can take a look at the code for the default actions in the Sails blueprints hook for a head start.
Adding custom blueprints is also supported, but they currently do not get bound to routes automatically. If you create a /blueprints/foo.js file, you can bind a route to it in your /config/routes.js file with (for example):
'GET /myRoute': {blueprint: 'foo'}
you can add actions with these names inside your controller to override default behaviour
to change destroy behavior
module.exports = {
destroy: function(req,res){
Goal.update({ id: req.param('id') }, { deleted: true })
.exec(function (err, goal) {
if (err) return res.json(err, 400);
return res.json(goal[0]);
});
}
}
It is possible to use the build in blueprints, but with policies running first. These policies might verify that the user is logged in, has the correct access, or similar. Really handy!
On each model, you have available callbacks both before and after data has been stored. Dig in: http://sailsjs.com/documentation/concepts/models-and-orm/lifecycle-callbacks
There is no default callback available for blueprints result. But don't give up. It is still possible to use the build in blueprints, and only modify the output. It might not be the most elegant solution, but it works well. Check out my “hack” here: Sails blueprints lifecycle
Using YUI scripts on our SSL page turned out to break the SSL connection because they dynamically load scripts from yahoo (combo) over a http connection.
As we only use the history manager of YUI 3, I wanted to host the code on our server. If I copy the code from http://yui.yahooapis.com/combo?3.2.0/build/yui/yui-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-base-min.js&3.2.0/build/dom/selector-native-min.js&3.2.0/build/dom/selector-css2-min.js&3.2.0/build/event-custom/event-custom-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/node/node-base-min.js&3.2.0/build/event/event-synthetic-min.js&3.2.0/build/json/json-min.js&3.2.0/build/history/history-min.js&3.2.0/build/history/history-hash-ie-min.js It does not work anymore ("Y.History.getBookmarkedState is not a function" says firebug).
Does anyone know how to do that correctly?
Thanks
You're loading the modules correctly, but you're trying to use the deprecated History API (from YUI <=3.1.x). In YUI 3.2.0, the History Utility was rewritten, and the API is not backwards-compatible.
You can still use the old API in 3.2.0 by loading the history-deprecated module instead of history. Alternatively (and preferably) you can migrate to the new API, which is simpler and more flexible than the old one. You'll find a migration guide in the History Utility documentation.
I guess you should check the API. I've checked the code from this combo and it really loads History and submodules.
YUI({ bootstrap: false }).use('history', function(Y) {
Y.log(Y.History);
});
It shows outputs G(); Also I found getBookmarkedState declaration inside history-deprecated submodule so it seems like something new is used instead of this.