I am using the SyliusCartBundle, SyliusFlowBundle and the SyliusOrderBundle in a project. So I have declared an own Cart, CartItem model and a CartManager. I'm using the cart without problems, but how can I convert this cart into an order?
Do I have to handle with an order model all the time?
What would be the preferred way to handle this use case in Sylius?
And where is the http://docs.sylius.org/en/latest/bundles/SyliusOrderBundle/builder.html? I can't find the OrderBuilder class in the SyliusOrderBundle.
What I figured is that in Sylius the only difference between cart and order is in the status.
What I mean is that there is only one order table and one order items table. When you add some item to your cart then it gets saved to the order/order items tables with a specific status, which will change once you check out, once you pay succesfully, etc etc.
It makes sense if you think about it.
So what converts your cart entries to order entries is the event listeners that respond to cart/order lifecycle events triggered by the controllers. In your case by the checkout flow.
The documentation is a bit old and in the process of being rewritten (I think).
Your best option in my opinion is to check out https://github.com/Sylius/Sylius
It is a full working app based on all the sylius bundles, and you can play with it to understand how it works. Check out the event listeners that the CoreBundle registers.
If you look into the CoreBundle/Model folder you will see that Sylius\Bundle\CoreBundle\Model\Order extends Sylius\Bundle\CartBundle\Model\Cart
HTH
Related
I would like to do some interesting stuff with the hits that are being displayed based on the search query that user is not only typing into search box but actually filtering using the instant search filters. I have filter based on hierarchical events_location taxonomy. Based on what user selected I would get the info in JS variable that I can then further use to do other operations in the hits div, specifically on each hit card.
So my URL when searching updates like this:
/what-to-see/?q=&idx=sdbeta_posts_events&p=0&hFR%5Btaxonomies_hierarchical.events_calendar.lvl0%5D%5B0%5D=JUL%204&hFR%5Btaxonomies_hierarchical.events_category.lvl0%5D%5B0%5D=All&hFR%5Btaxonomies_hierarchical.events_locations.lvl0%5D%5B0%5D=Paddock%20Stage
I could potentially take the URL and extract the data from it, but I am sure there is more elegant way of working with the query.
In InstantSearch.js, the state is managed by another library called the algoliasearch-helper. Through this library you can read and write the search parameters.
The cleanest to access the helper is to build a custom widget, which is a plain object with lifecycle hooks (initial rendering and the other renderings). You can read more about custom widgets there.
Once you've accessed the helper, you can read and write with the helper API.
This can be found under search.searchParameters
So:
console.log(search.searchParameters);
Will give you whole object that you can then work with.
There is however one issue with this and that is that it works only on initial load. I was unable to make this work or get any data after starting to selecting categories. So if anyone knows how to use this so it updates after each selection please comment bellow.
All of my codes are in extensions.
I've added a field into the table, and also added that field into the assigned field group.
Now it is visible on my Design.
and I want to place a code into the event of it where it is modified.
So I've created a new class, then get the event handler.
But when I paste it, there's an error and I checked the intelisense and it can't see the field I placed, well in fact, it is there:
How can I use my newly added field? Is there something I am missing?
I can reproduce this problem in Platform Update 8. It seems to be a limitation of the product when working with controls added through field groups.
Nevertheless the solution is simple - use Modified event of the datasource field, not the individual control. That's what you should do in most cases anyway, because one field may be displayed at several places, but it should do the same thing when modified from either of them.
You can use the registerExtensionInstance method as described in this blog post and register override of the required control's method from method new.
You can see how the registerExtensionInstance pattern is used in a number of classes in AX:
CaseDetailEventHandler
DirPartyQuickCreateFormApplicationSuiteEventHandlers
EssWorkspaceFormExtensionAppSuiteEventHandler
EssWorkspaceFormExtensionExpenseEventHandler
FormControlQuickPersonalizationTileExtension
HCMCaseDetailCreateEventHandler
HCMCaseDetailEventHandler
HcmCaseDetailEventHandler_HcmWL
HcmEnrollmentDateManagerFormExtensionEventHandler
HcmJobFormExtensionRetailHandler
HcmPositionActionDetailFormExtensionPayrollHandler
HcmPositionDateManagerFormExtensionPayrollHandler
HcmPositionFormExtensionPayrollHandler
HcmPositionMassUpdateFormEventHandler
HcmWorkerDateManagerFormExtensionPayrollHandler
HcmWorkerEnrollmentFormExtensionPayrollEventHandler
HcmWorkerFormExtensionPayrollHandler
HierarchyDetailEventHandler
HRMCourseInstructorFormExtensionAppSuiteHandler
smmActivitiesEventHandler
smmContactPersonFormApplicationSuiteEventHandlers
SysGenBlankWorkspaceOptionsPowerBIExtension
I have a content type which has a lot of fields 50+. 30 or so are required fields. I want my user to be able so save the node before all the required fields have been filled in. The node can not be published until all the required fields have been filled in. Is there a way I can do this.
Not directly. Required fields are exactly that. You'll need to make your fields optional and handle the node save event and prevent publishing until each of the fields has been filled in. If you don't feel like all that php, Rules module can handle this kind of thing very nicely - http://drupal.org/project/rules.
Another alternative is that you might be better off with something like a webform - http://drupal.org/project/webform, though I don't know if it has any save and resume functionality out of the box so you might need to check that out first.
This module will do the job:
http://drupal.org/project/multistep
You can split your form to steps and only the fields in the current step have to be filled by the user.
I have the following scenario:
Editor Role should not be allowed to
delete nodes. Therefore the corresponding
permission is de-selected in the
permissions page.
However Editor
should be able to to delete nodes
from Views Bulk operations. Using
Rules an action is created called
"safe delete" that checks things like
if the node is not published etc.
before deleting the node.
The problem is the Views Bulk Operations respects Node permissions. Editor will not be able to delete the node as he has not been given that permission. Is there a way that Editor can become a higher role user (as sort of sudo) while performing that action in VBO? Alternatively is there a way to tell VBO to ignore node access for this action?
I'm sure this is a mainstream requirement but I can't seem to find a solution.
Solutions which do not involve programming will be preferred.
The simple, but not-so-clean way, is the route you already took, but with an additional, small module to help it.
has a function my_module_can_delete($user), that returns TRUE if the user is allowed to delete, FALSE if the user is not.
implements hook_form_alter() to modify and delete the button on the node_edit form, if my_module_can_delete($user)
implements hook_form_alter() to modify the confirm form that is called on /node/%nid/delete, and add a message there, telling the user he or she my_module_can_delete($user). This should be enough, since disabling this form will result in users not being able to get past this form. FORM-API will take care of that.
However, you can make it more sturdy, to catch other deleting modules:
implements hook_nodeapi(), $op == 'delete' to catch delete actions and halt (by invoking drupal_goto(), or calling drupal_access_denied() to enforce a user-error. Only catch delete-actions if the referer was the delete-confirm-form as mentioned above. Or, more secure, whitelist your VBO-action and return false on all other referers. A referer can often be found by reading out the $node passed along to hook_nodeapi().
A, IMHO, much cleaner, but probably more intensive alternative, would be to simply make sure your batches/actions are called on every delete action.
In a module, you could do this by avoiding all the VBO-configuration and leaving all the extra-delete actions out of there.
Then write a module that implements hook_nodeapi() and then calls all the cleaning actions from there. That way you can be sure that your delete-actions are called on every delete-action on any node. Obviously you can add some conditions into your hook_nodeapi() to only invoke your modules in certain cases (node-types, user-roles, permissions and so on).
Well, it seems to me that you've got a setup where you don't want Editor Role users to delete things, really, except in certain extreme situations. Here's my suggestion:
1) Install Flag module. Create a 'To Be Deleted' flag that can only be assigned by Editor Role people.
2) I haven't looked into it, but I"m sure there's probably a rule or trigger/action combo which will unpublish the node when the 'To Be Deleted' flag is assigned to it. This will remove the node from casual view.
3) Then either set up some cron run activity (trigger/action or rule) to delete nodes with 'To Be Deleted' flag set on them, or have another user with higher permissions come in occasionally and delete out the flagged items.
This way you're not actually bypassing the permissions system, and yet things are still being removed from your site.
I got caught out of this for a while until I noticed the "actions_permissions" module, enable this and on the Permissions page you can provide access to specific actions on a role by role basis.
I don't have a good no-coding solution, and I'm not sure I would call this solution "great" - but one way might be to implement a simple module with a form_alter hook that removes the delete button from the node edit forms as they are built.
In general it seems like the role either has permission to delete nodes or not, and monkeying around like this is going to be less robust that you might like.
I'm building a Drupal based site that requires the communication of a node ID to a seperate web service. This web service handles the uploading of files to a seperate server (from the one Drupal is on).
This creates a problem where in if I create a new node, the Node ID is not generated until the form is submitted - meaning I can't attach the files until I save the node and open it back up to edit it. I'd like to remove that step.
Is it possible to create a two step node creation process where the basics of the node are submitted and saved, and then the form re-directs to step two where I can attach the files?
I'd also consider an AJAX enabled node submission form - but that seems to add even more complexity to the situation.
Any advice, examples will be appreciated!
you could do this with a multi-step form. see http://pingv.com/blog/ben-jeavons/2009/multi-step-forms-drupal-6-using-variable-functions for the canonical way to do this (besides the code, also check the comments).
you could also do it by adding a second submit handler to the form. the first, default one (node_form_submit) saves your node (including the attached file) the standard Drupal way. the second handler could upload the file to the separate server, do upload error checking, delete the file from the Drupal DB, etc. you can add an additional submit handler to a Drupal 6 form by adding it to the form's #submit property, either in the form definition or via hook_form_alter / hook_form_FORM_ID_alter.
Depending on what exactly you want to do, you might use hook_nodeapi on its 'insert' operation. It is fired after successful node creation, so the node object will contain the newly assigned nid there already.
NOTE: The wording of the API documentation is a bit ambiguous concerning the 'insert' and 'update' operations:
"insert": The node is being created
(inserted in the database).
This sounds like it is right in the middle of the process, whereas the node has already been created at this point.
I guess the node_save function can help you.
I ran into exactly this same issue and did it the wrong way. I added the hook myself.
http://drupal.org/node/313389