I need to change default success message when we get after creating an item into my own success message. After few digging I found out how to create new flash messages but change existing messages is still a mystery to me.
This is my config.yml file
#app/config/config.yml
sonata_core:
flashmessage:
success:
types:
- { type: mytodo_success, domain: AdminBundle}
Admin class,
public function postPersist($object) {
$this->getRequest()->getSession()->getFlashBag()->add("mytodo_success", "My To-Do custom success message");
}
It would be great if someone can help me on this. I need to change default success message witch gives 'flash_create_success' to my own message.
You can create your own "translation" file .. and put it in your local resources... here's the original
https://github.com/sonata-project/SonataAdminBundle/blob/master/Resources/translations/SonataAdminBundle.en.xliff
the success message lives there ... just change the English "translation" to whatever you need... if you are using <= symfony 2.8 you can put the file in
app/Resources/SonataAdminBundle/translations/SonataAdminBundle.en.xliff
after clearing your cache.. you should be able to see new message without doing anything more...
Related
When I develop templates in Sulu 1.6 and an error occurs, where can I find the full error or exact error location? Is there some kind of special log or do I need to change the default location?
The corresponding /admin/websocket/admin response contains only this (basically the same information):
{
"handler":"sulu_preview.preview",
"message":{
"code":9903,
"message":"Unclosed \"block\".",
"type":"Sulu\\Bundle\\PreviewBundle\\Preview\\Exception\\TwigException"
},
"options":[],
"error":true
}
Currently I only see messages like this:
It would be also helpful to know, where the catch block for this is, in case it is not jet implemented.
Thx a lot!
So it turned out, that there is no logging enabled, and because the PreviewRendere throws a new Exception, the original information is pretty much lost. It can be added in this way: https://github.com/sulu/sulu/pull/4363
Best wishes
Andreas
While trying to understand why my view is not displaying, I noticed the following error in the log:
I do not think it is possible to delete the URL alias from Taxonomy terms. At least I cannot find how to do this.
I have, however gone through ALL of my taxonomy terms and removed the value for this field.
I have also done the following with Pathauto:
Also, I have checked the report located at admin/reports/fields and can confirm that there are no entities that use a field called URL alias.
I have gone through each content item and ensured that they have the following setting (anyone know how to do this in bulk?). But still the error remains.
Anyone know then how I can fix this strange error?
Im not entirely sure what this command does, but it fixed the error:
drush updb --entity-updates
Since https://www.drupal.org/node/2554097, the magic in Drupal core that took care of updating entity definitions is gone. drush updb --entiy-updates is an alternative to this but it is not a silver bullet. Instead, it is safer to write database updates.
Taking the screenshot at the top as an example, here is a database update that would delete those two field definitions:
/**
* Fix taxonomy and node field definitions.
*
*/
function mymodule_update_8101() {
$manager = \Drupal::entityDefinitionUpdateManager();
if ($field = $manager->getFieldStorageDefinition('alias', 'node')) {
$manager->uninstallFieldStorageDefinition($field);
}
if ($field = $manager->getFieldStorageDefinition('alias', 'term')) {
$manager->uninstallFieldStorageDefinition($field);
}
}
Have a look at the rest of the available methods at https://www.drupal.org/node/2554097 in order to write database updates for each scenario.
use the entity_update module or the devel_entity_updates module
I have this in my routes.conf file:
# SecureSocial routes
# Login page
GET /login securesocial.controllers.LoginPage.login
And then I have this in a Scala Controller file
val index = SecuredAction { implicit request =>
Redirect(routes.UserOps.watchlist)
// how do I go straight to /login? >|
}
Doing this takes me to a login page that has a red error bar saying "you must be signed in to view this page". If I access `localhost:9000/login' I get the login page without the error bar.
Normally I do a Redirect(routes.SomeControllerObject.ActionMethodName) but in this case the controller I need to access is in a plugin...
I feel like I'm missing something rather large here...
Update:
To reverse-route to an action in a plugin controller you need to provide the correct, full path to the plugin's routes class.
Redirect(securesocial.controllers.routes.LoginPage.login)
Original Answer
For reverse-routing I don't think it matters where the Controller is since Play is building that when the project compiles. From the documentation:
For each controller used in the routes file, the router will generate a ‘reverse controller’ in the routes package, having the same action methods, with the same signature, but returning a play.api.mvc.Call instead of a play.api.mvc.Action.
So this should work just as if LoginPage was a controller directly in your app.
Redirect(routes.LoginPage.login);
In order to show the message, you must have an item in the Flash. When you hit /login directly, there is no flash, so you won't see that message.
If you want to see that message:
Redirect(securesocial.controllers.LoginPage.login).flashing( ... )
I created simple HttpModule, all what I need is just get is valid Sitecore.Context inside but during processing I see that my Sitecore.Context is some kind of default.
I can get Sitecore user that log in to Sitecore, etc.
How to fix it ?
I assume you have a Sitecore Context, but it is null or set to the wrong site or language.
You can change the context like this:
// switch to the preferred site
Sitecore.Context.SetActiveSite("yourSiteName");
// set the preferred database
Sitecore.Context.Database = Sitecore.Configuration.Factory.GetDatabase("master");
// set the preferred language
Language language = Sitecore.Globalization.Language.Parse("en");
Sitecore.Context.SetLanguage = (language, false);
You probably also want to switch back to the original settings after your processing is done. So it is wise to "save" the original settings in a variable so you can change them back afterwards
Take a look at John West's posts on Sitecore pipelines for some background on how the context is being established.
http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/05/All-About-Pipelines-in-the-Sitecore-ASPNET-CMS.aspx
and
http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/05/Important-Pipelines-in-the-Sitecore-ASPNET-CMS.aspx
The following blog post on creating and running custom pipelines should give you an idea how to implement your own pipeline.
http://adeneys.wordpress.com/2008/08/27/creating-and-running-custom-pipelines-in-sitecore/
This error suddenly occurred when Pressflow was added to our Drupal installation. It is coming from a custom module that, prior to Pressflow seemed to work fine. After the addition of Pressflow, running Drush causes this error to display on screen.
The function that is identified as the source of the error looks like this:
function user_search_location_get(&$user) {
if (count($user->user_location_pref)) { // This line is causing the error.
return $user->user_location_pref;
}
// …
}
The error message is the following:
WD php: Notice: Undefined property: stdClass::$user_location_pref in user_search_location_get()
Short answer, in your custom module, you should check if that property exists before you count it. That, or make sure the $user object has that property before you use it.
if (isset($user->user_location_pref) && count($user->user_locaion_pref) > 0) {
return $user->user_locaion_pref;
}
While it is a little more work, when you start developing with notices turned on, you will find errors in your code that otherwise would have not appeared till later, and would have been more difficult to track down.
In your previous environment or install, the PHP error reporting was probably set to not show notices. While I recommend keeping notices on and making your code work with them, you can turn them off through the Drupal 7 UI. Configuration -> Development -> Logging and Errors. Then set the value to 'Errors and Warnings' ... Otherwise, you can set your error reporting level in your php.ini to report all except notices.
Note that Drupal 6 did not force notice reporting on, while Drupal 7 does. That prompts this type of question a lot.
If this is your only notice issue though, it makes more sense to just correct your custom module.