I have here a magnolia 6.2.3 installation where the edit dialogs are too wide (full screen width):
I compared the markup with the markup from demo author and noticed that some css classes are missing.
It looks good when i add the medium class to the root node of the markup.
How do I get magnolia to render the correct markup?
My guess was that I am using an outdated widgetset, but the magnolia-vaadin-widgetset-pro:6.2.3 is used.
More information:
It is a migration from 5.5.8 to 6.2.3.
It affects all Magnolia 5 UI dialogs also system dialogs. It does not occur in the new Magnolia 6 UI apps like pages-app or dam.
See for example from the About Magnolia app:
Markup:
As a counterexample, the same dialog from the demo instance:
Edit2:
Ok, it seems to be a problem with the specific Magnolia version. I can recreate the problem with mgnl jumpstart -m 6.2.3. With 6.2.4 the problem does not occur anymore. Unfortunately an update is no option, I will invest a few more hours to find a solution.
In all likelihood, the dialog definition for your dialog is set to be wide. See wide property of the dialog in the dialog definition documentation.
The problem was with the specific Magnolia version.
It can be easily reproduced with mgnl jumpstart -m 6.2.3.
Who can should update. It seems to be fixed in 6.2.4.
Unfortunately I can not update my project.
The most painful problem (description fields in the dialogs are not readable) I could fix by updating magnolia-vaadin-widgetset-pro to 6.2.4.
Related
I have been building small "proof of principle" programs to learn about GTK3, and now that GTK4 has limited availability, I have been attempting to learn about this version as well. In attempting to migrate to GTK4, I took a program I wrote for GTK3 that displays two progress bars with different attributes using CSS providers and rebuilt it under GTK4. When I ran the GTK4 version of the program, the CSS overrides in the program are ignored unless I introduce the CSS provider context to the display level for one of the progress bars. But that then results in having both progress bars exhibiting the same behavior instead of having unique behavior for each progress bar. Just as a further test, I added CSS providers and context for a label widget and that override worked. So some CSS overrides in GTK4 work as before, but some do not. It is as though some CSS provider overrides are ignored at the display level. Reviewing documentation about priorities (e.g. GTK_STYLE_PROVIDER_PRIORITY_APPLICATION) and testing out various priority constants did not make a difference.
Displaying the content of the code would be too long in this narrative, so I have uploaded the GTK3 and GTK4 versions of the code to my Github repositories along with a "pdf" file visually illustrating the different behavior between GTK3 and GTK4. If you want to review and test out the code yourself, the link is:
https://github.com/cschuls/GTK4_Mystery
I would suppose that widget-specific CSS customization could be added at the display level with an "id#" attribute, but that seems like that would just be adding unnecessary complexity when this practice works fine with GTK3. Thanks in advance for any answers and suggestions.
Additional comment.
Experimenting with various scenarios, I came up with a work-around that provides the desired result of having distinct style properties applied to each progress bar widget. For those widgets, I added their respective CSS provider data to the display style context instead of attempting to add the CSS provider to each widget's context. If you wish to view this work-around, I added a "work-around" folder with the source code to my Github repository.
This provides a decent solution to this problem, but it does not answer my underlying question as to why the CSS provider information for each progress bar widget is not enacted upon during the application's execution; whereas, CSS provider information associated with widgets such as labels and buttons do behave as they did with GTK3. If anyone can answer my core question, I would be very happy.
Regards,
Craig
Working on the 3.1.14 version of OroCRM, I don't have access to the "related entities" on the "Columns" part of the segment or report designer (see image 1 on the 3.1.14 version)
It was working on the 3.1.x-dev as you can see on the picture 2.
Please note that he related entities are still available on the filter part. (see picture 3 on the 3.1.14 version)
Can you help me to resolve this ?
Thanks.
This functionality was disabled intentionally as there are some issues related to UI performance and complexity, so it would not be supported officially anymore.
However, you can enable it back, at your own risk, with the simple form type extension for Oro\Bundle\MarketingListBundle\Form\Type\MarketingListType to override column_column_field_choice_options option. But in this case, you should handle the performance issues on your own.
I'm having an issue with the "browse for items" overlay for the default widget for z3c.relationfield, which I believe is using plone.formwidget.contenttree. I've created a custom field using this but get the same problem using the IRelatedItems behavior - the overlay has no browsable content. I am still able to use the autocomplete component of this widget, and can set relations programmatically with no problem, so I don't believe there is a problem with the intids utility. I've also tested on my local machine and on a dev server and everything works perfectly, just not in production (of course).
I apologize for the vague nature of this question, but I'm stumped. Are there any common pitfalls I could look for here? Any configuration step I might be overlooking?
Take a look at the Dexterity documentation and note the following:
Relation support no longer included by default
Content tree and Autocomplete widgets no longer included by default
So maybe you need to install the widget packages manually.
I am new to Sitecore and have questions. I have installed Sitecore version 7.1 several times just for the fun of it, sweet. Now, I am attempting to follow a tutorial of “Building A Very Simple Website”
http://sdn.sitecore.net/upload/sdn5/developer/training%20materials/basic%20site/selfstudyguide-buildingaverysimplewebsite_usletter.pdf
This tutorial is targeted for Sitecore CMS 6.2, so I want to confirm if it’s still accurate.
The instructions for creating a Generic sublayout display file says I should be able to access the Grid Designer and insert a control while in the Content Editor. I am not seeing any option for this. The only way for me to access the Grid Designer, is by selecting /Development Tools/Development Center. And when I do this I can insert a control but it’s not saving any of my changes.
As anybody had this problem?
Is that tutorial still valid?
I had this same question. I'm running sitecore 7.1 but am following an outdated self study guide for sitecore 6.2. I was able to resolve doing the following.
From the Desktop interface, open the start menu
Open Development Center (Listed under Development Tools)
Select 'Create New Sublayout'
Once created the options you seek will be available
This is the start page for the Developer Center
This will open automatically when you finish the Sublayout creation wizard
The grid designer is still there. It relates to Sublayouts, so if you go to /sitecore/layout/Sublayouts and select one of the sublayout items, you should then see the grid designer tab:
Towards the top right of the screen you should see some tabs for dislaying layout and format options:
To be honest, you'll rarely (if ever) use the grid designer again after this tutorial, so don't worry to much.
I had same problem with Sitecore 8 and solved it creating Sub Layout,going though development center as shown above by #Tyshun. Else
Go direct to development Center using url http://{{Your Site Name}}/sitecore/shell/default.aspx?xmlcontrol=IDE.
You will get option to create SubLayout and then you will get grid view design option.
I would like to move modules via drag and drop as an admin. It would have to trigger those same "Move to X Pane" links? I saw this link that shows dragging and dropping modules as an admin for layout, but could not get it to work.
Am I missing something or is there an extension for this? I am trying this on the latest DNN 6.0 by the way. Thanks for any help.
Wow, that guided tour is super old. I believe it was DNN 5 where that behavior was changed to only work in layout mode. Once you switch into layout mode, you should be able to see the panes and drag the modules between them (by their titles).