7

The gist is, you will need to give your plugin a dedicated Settings model class, where you will have complete control over its validation rules and errors. Here’s how to set that up: Create a new Model class whose defineAttributes() method is based on your plugin's current defineSettings() method. class Foo_SettingsModel extends BaseModel { protected ...


6

I got around this issue by looping through all fields that were of BaseElementFieldType re-setting them to their current value. $fields = $entry->getFieldLayout()->getFields(); $referentialFields = array(); foreach ($fields as $layoutField) { $field = $layoutField->getField(); if ($field->getFieldType() instanceof BaseElementFieldType) { ...


5

If you use $model->getErrors() instead, it should return a multidimensional array of errors indexed by attribute name like so: array( 'email' => array( 'First email error.', 'Second email error.', ), 'firstName' => array( 'First firstName error.', ), ); Or you can get errors specifically for an attribute ...


5

As carlcs said, this is already working as expected. Craft only enforces content validation rules for enabled entries (not including drafts), and most people prefer that behavior. If you want to change that behavior, you can write a plugin that provides its own entry validation logic, by latching onto the entries.onBeforeSaveEntry event. Just put this in ...


4

You can pass the element off to ContentService::validateContent() in the event that it doesn't pass the record’s validation, just to get those errors mixed into the element as well. if (!$record->validate()) { // Copy the record's errors over to the element model $element->addErrors($record->getErrors()); // Might as well validate the ...


4

You're very close. Try this: $entry->getContent()->setAttribute('metaStatus', 'Declined'); craft()->entries->saveEntry($entry);


4

As other answers have touched on, the behaviour you're seeing is by design. I've written a plugin called Always Validate which will make Craft validate all disabled entries and categories – including entry drafts or entries saved by users not permitted to publish – which should solve your issue.


4

You can do either or both of: Use javascript validation on the front end (with e.g. parsley) Create a plugin with a method that is registered as a listener on this event: https://craftcommerce.com/docs/events-reference#commerce_addresses.onbeforesaveaddress ...and perform validation on the address model before it is saved. use $event->performAction = ...


4

I don't know if there is anything natively in Craft to do this, but you could achieve it quite easily with a single file plugin: public function init() { craft()->on('users.onBeforeSaveUser', function(Event $event) { // Only do anything if it is a front end submission if(craft()->request->isSiteRequest()) { $...


4

You can create a custom validation at the EVENT_BEFORE_SAVE event Event::on(Entry::class, Entry::EVENT_BEFORE_SAVE, function(ModelEvent $event){ /** @var Entry $entry */ $entry = $event->sender; // you can check for the section and the type $model = DynamicModel::validateData(['title' => $entry->title], [ ...


3

There's no clean way doing this without making changes to the plugin itself. The contactForm.beforeSend event makes it possible to prevent the email from being sent from another plugin, but you're only being passed the compiled email message as a string. It's probably possible to post you checkbox data with that string and parse for it in your event ...


3

In your FieldType you have $this->element available, representing the Element the field is in. If you use $this->element->lightSwitchHandle you can access its value.


3

Have a look at the segments property (shortcut for getSegments() method) of the HttpRequestServices class, which returns an array of uri segments. craft()->request->segments; To get the last segment you could use php's end() or array_pop() method. $segments = craft()->request->segments; echo end($segments);


3

I can think of a couple of options and I'll just throw them all out there. Have a separate model per partial form and each model performs its own validation. Have a single model, but have it override the rules() method and you can conditionally set what validations methods you want depending on the step you're on. Presumably, you'd want to pass in a step ...


3

It sounds like you're on the right track. You could create a custom validator, as detailed here. <?php namespace Craft; use Carbon\Carbon; class MyPlugin_ExampleModel extends BaseModel { protected function defineAttributes() { return [ 'startDate' => [ 'type' => AttributeType::DateTime, ...


3

No, I don't think there's a better way, you need to add that conditional to each select option. But what you could do is to refactor a bit and move that logic to a Twig macro. {% macro stateOption(id, name, selectedId) %} <option value="{{ id }}"{{ id == selectedId ? ' selected="selected"' }}>{{ name }}</option> {% endmacro %} {% import ...


3

Be sure that you're testing as a logged-out user on the front-end of the site. If you have an active Craft session, you could be getting a false positive error message.


3

I'm not completely sure of the technical reasons (I guess something to do with relation fields not have a column in the craft_content table), but you also need to re-save the existing ids for any relation fields (Assets, Entries, Categories, Matrix, etc) before the element can be saved: $entry->setContentFromPost(array( 'metaStatus' => 'Declined',...


3

I believe you're looking for the aptly named autoLoginAfterAccountActivation config setting.


3

That's the idea behind Drafts, to store entries not yet ready to publish, unfinished ones so to speak. I think it does make sense to not validate the fields. Good feature!


3

Yii/Active Record won't do this by default. You'd need to manually add an exists validation rule to the typeId attribute to get it to behave like you're looking for.


3

You could use Regex (Regular Expression), /^[a-zA-Z]{3,}$/ would for instance allow a minimum of 3 characters behind the comma would be the max value. As for numbers it would be something like this /^[0-9]{3,}$/ http://regexr.com/ to test your regex en examples And I would do this before the user is saved with the users.onBeforeSaveUser Event in a plugin.


3

It will be possible in the next release (commerce 2-beta.5): https://github.com/craftcms/commerce/issues/342


3

Address validation is, in Commerce v1 at least, generally handled via a plugin. (I'll assume you already have a business logic plugin on the go, but if not head over to https://pluginfactory.io and use that to generate your plugin skeleton). Then, you basically need to add a listener to onBeforeSaveAddress and do your validation in that. In your plugins ...


3

Here's my findings after some experimentation: Elements and Records are two entirely separate entities. The Element is basically the core Craft database entry, while the Record is the additional database entry in a new table with your custom fields. Validation should always be done on the element if you use the pattern used in the question, because ...


2

I ran into this issue too, but there is another cause to this error. Go into Settings > Users > Settings in the Control Panel and ensure "Allow public registration?" is checked, it's unchecked by default. Then it's also worth adding a conditional to the registration page to test if they are logged in or not, to ensure the error can never be triggered for a ...


2

Custom field validation happens automatically for you when you pass your element into craft()->elements->saveElement(). That function will return true or false, largely depending on whether custom field validation passes. See EntriesService::saveEntry() for an example.


2

This might be similar to Brad Bell's recommendation, but if you are using Yii's built-in validation rules, you should just override the rules() method in your model or record, specify the rule there, and then customise the error message text for it. For example: /** * Returns this record's validation rules. * * @return array */ public function rules() ...


2

In addition to Brad’s answer (which is what I was looking for), you could also use template-specific messages using conditionals if for some reason you only needed to override the global error in a certain place. Unlikely but here’s an example: {% if errors.attributeOne is defined ? errors.attributeOne | length %} <p class="alert">Custom ...


2

You're correct. Craft will not run validation upon saving disabled elements. This is not a bug – it's just designed that way (as far as I can tell from looking at the relevant source code in the ElementsService). As for a workaround – you'll need a plugin. This is the easiest approach I can think of: Listen for the entries.onBeforeSaveEntry event In the ...


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