13

You should be using setContentFromPost() rather than setContent(), so that field types have a chance to prep the values that you are passing in. See “What is getContent() / the ContentModel, and how do I use it to get and set custom field values?” for more info on how this stuff works.


8

This is Leslie, I'm the Chief Customer Officer for Craft CMS. I'm not sure I can help, but I'd like to know more. Specifically I'm not sure I can source a dev shop in Germany, but I may be able to get close. We do have Service Partners and we are privately testing a couple of service plans both directly from us and from contracting 3rd party shops that ...


6

Something like this should work: public function add($user) { $existingUser = craft()->users->getUserByUsernameOrEmail($user->username); if ($existingUser) { // They exist... log them in. craft()->userSession->loginByUserId($existingUser->id); } else { // They don't exist... create them. ...


6

I am just iterating on the previous answer to attempt to explain why this is happening. If you take a look at BaseElementModel.php at the setContent() method. You'll see that the core code is doing pretty much the exact thing as: $entry->getContent()->setAttributes(array( 'foo' => 'bar', 'xyz' => '123' )); The core confusion seems to be ...


5

Looks like a casing issue to me. You should be calling: craft()->campaignReports_campaignMonitor->getSettings();


4

Have you tried using that form of setting with this method instead? $entry->setContentFromPost(['foo' => 'bar', 'xyz' => '123']); There's also this method: $entry->getContent()->setAttributes(array( 'foo' => 'bar', 'xyz' => '123' )); As to the specific question of why doesn't setContent() work as expected, I can only guess that it ...


4

As far as accessing the value of the setting, try: $plugin = craft()->plugins->getPlugin('pluginHandle'); $plugin->getSettings()->getAttribute('pluginSettings1'); If you need to access your settings throughout your services file you might also create a global variable. class PluginHandleService extends BaseApplicationComponent { public $...


4

There are several ways you could go about this. One that I tend to prefer is to go ahead and have your controller grab whatever data it needs from POST and populate a Model with it. That model is what gets passed into your service layer. Your service layer can run validation on the model (if any validation fails, you can retrieve the errors with $model-&...


4

Try it with a lowercase f in the middle... craft()->fulcrumDonation_fulcrumCyberSource->exampleService();


3

As of this commit, there is a Craft::$app->getVolumes()->getVolumeByHandle($handle) method you can call.


3

If you have an EntryModel and know the category field's handle, you don't really need a service: $categories = $entry->categoryFieldHandle; In other cases, you can construct an ElementCriteriaModel to search for related elements (categories, entries, users or assets), using a number of different variables. Easy example to get related categories from an ...


3

Something on the $entryToSave EntryModel is failing validation. If you echo out implode(', ', $entryToSave()->getAllErrors());, then you'll see what those errors are and you can correct them.


3

Well, it looks like Sprout Forms itself prefers separate services for everything (they'd be some big services if they weren't,) but Craft does bundle closely-related things together sometimes - FieldsService deals with both fields and groups, TagsService with both tags and tag groups for example. Personally I just look at how much code there is, if I start ...


3

Ok, so I finally figured it out. The trick was using the following two methods: assembleLayoutFromPost() setContentFromPost('fields') The controller now looks like this: public function actionSubmit() { // require POST $this->requirePostRequest(); // assume new element type $elementtype = new PluginName_ElementTypeModel(); // assign the attributes ...


3

You can use the FrontEnd Entry Form for this. If you want to allow guests (non-registered users) to submit the form, you need to use the Guest Entries plugin. Both methods will set "publishing date, id, etc" automatically, you just need to specify the title in the form. If you want to hard-code some field values and prevent the user from changing it, you'd ...


2

Yii's setAttributes method is probably a better way to do this than the populateRecords method, as by default assignments will only be made to safe attributes. See this wiki article, Understanding "Safe" Validation Rules , for details on how you can specify what attributes are safe to be massively assigned. This will allow you to protect against unwanted ...


2

Yii does have the equivalent populateRecord and populateRecords on CActiveRecord. However, on both the populateModel(s) and populateRecord(s) methods, you should be very cautious of blindly mass-assigning untrusted inputs to models/records that participate in the Active Record pattern (like Craft/Yii does). They can be susceptible to what's known as the ...


2

I suspect you're getting different session IDs because you're creating a new instance of HttpSessionService (which ultimately is a wrapper for PHP's session handling). What you should be doing is using Craft's existing session off of craft()->httpSession and grab the existing PHP session ID with craft()->httpSession->getSessionID(). No need to ...


2

Your service’s init() function gets called immediately after it is loaded – and before Yii has had a chance to remember that craft()->myPlugin should return the service instance. Take a look at these two lines from CModule::getComponent() (the method that the magic getter invokes when you call craft()->somePluginName): $component->init(); return $...


2

Are there technical reasons for this recommendation, or is it something you'd just rather not support? It's more along the lines of it's something you're not going to want to support. The problem is that things like services and records change over time. Methods get renamed/deleted, attributes change, parameters change, etc. By using them in a migration ...


2

Not 100% sure what is going wrong here, but here is what I would do to debug this on my end: Simply output the current path the template parser is using in the controller and event handler to see the difference in the values var_dump(craft()->path->getTemplatesPath()); exit(); If the values are different, you can override the value to do your ...


2

Craft will only look in the immediate pluginHandle/services folder when auto-loading and registering a plugin's service files. If you wanted to support services in subfolders (i.e. pluginhandle/services/subfolder1, etc.), you'd have to manually autoload and register those classes yourself from your plugin's init() method.


2

Craft 2.x includes Guzzle 3 natively, so you could write a Craft plugin that uses it to consume your web service. There are plenty of examples in the Guzzle 3 docs on how to do that (as well as in Craft itself). You could also use something like this: https://straightupcraft.com/craft-plugins/guzzle Which is a wrapper for Craft's Guzzle 3 you can use from ...


2

As you've discovered, you should be using the more generic elements.onBeforePerformAction or elements.onPerformAction events. They get fired when any action takes place and you can check their action parameter to determine if it was a SetStatus action.


2

Assuming Plugin1 is their main plugin class file name, you could do: \fully\qualified\namespace\Plugin1::getInstance()->myService->myMethod(); In order for this to work: Craft must be installed. Plugin1 must be installed and enabled in Craft. Composer autoloading has to be working so that it knows where to find Plugin1 If you're doing this from a ...


2

Have you tried running ./craft setup to double check if your setup is correct? If ./craft setup completes successfully ./craft should find the existing installation and complete any required setup. In my experience, this is usually related to a non-default /config/db.php or problematic .env file. Note: Always do a backup before trying anything related to ...


1

After taking a look again, it turned out to simply be an issue with the scope of the array and a therefore empty array as a result. Works as expected now.


1

Rather than assuming that the providers will live in a specific location, I'd be inclined to implement a custom hook, which allows third party plugins to register a new provider. This also allows third parties to do any initialisation of their provider, prior to handing it to you. For example, your plugin could do something like this: $providers = craft()-...


1

Had to browse through your plugin repo for a bit to try and wrap my head around what's going on, but I think you have the problem nailed down in that the issue is this: https://github.com/iNalgiev/webtexttool1/blob/1.0.0/WebtexttoolPlugin.php#L57 Trying to grab the entry ID from the cp.entries.edit.right-pane template hook for a new entry is going to return ...


1

OK, I managed to figure it out and I'll post the solution for those who run into similar problems. Essentially, what's happening is Twig template->Plugin controller->Plugin Service->Laravel API->Laravel Controller->Database The code: //Plugin controller public function actionPositionGuide() { $this->requirePostRequest(); $attr = json_decode(...


Only top voted, non community-wiki answers of a minimum length are eligible