For some problem in globalization(
orchard cms built in datetime field)
,I need to change datetime related shapes in all existing modules, the shapes includes (I think):
Parts.Common.Date.Edit.cshtml
DateTimeRelative
DateTime
How can I change all of these shapes in all existing module?
The changes are: adding some script to editor and some special formatting in other two shapes.
And finally if I changes the above three shapes, then all date related input and display in all place in orchard site would be changed?
I read lots of articles for doing this but i can't understand well.
The problem will be that those shapes are mostly in the admin. One thing you can do is take a dependency on the module defining them (in module.txt) so that your templates can take precedence. But changing the shapes probably won't be enough and you'll probably have to get your own driver in there to fix the dates on the way back. That being a little trickier, what I would probably do is handle all the locale-specific stuff in script on the client-side and send back to the server a date that has already been converted back to Gregorian calendar.
Related
Have anyone tried to have a form with MultiValueField in Magnolia having Composite fields with i18n enabled and is working properly?
Currently, I'm encountering some weird behaviour when adding items to English then switching to other language and adding items again then switch back to English with items all gone. In one JIRA post it said it was already fixed but I still encounter this issue. Also encountered issues in sorting which apparently not supported by the DelegatingMultiValueTransformer.
If so, can you please show me the configuration you use to make this work properly? If needed customisation, can you give me ideas on how to do it?
Would really appreciate any help on this.
Btw, I'm using the latest release 5.4.6 now.
Maybe you don't want to put two questions in one request in the future ;)
Re language issue:
did you check that you have i18n enabled also on the subfields, since you are using deletage transformer? AFAIK with delegate you need to have them enabled on all fields in the hierarchy.
Re transformer & ordering:
IMO the only way out is to write custom transformer. Look at source code of MultiValueTransformer and in the part of the code where it goes just two levels down when checking child values, you need to go deeper.
You would also need to define different structure storage for your values there since one used by the MultiValueTransformer would not suffice for multiple levels.
Perhaps you can extend one of the more specialized MultiValue*Transformer or perhaps you try MultiValueJSONTransformer if storing all values in json array is enough for you (you would still need to extend it and to repopulate values back into dialog when opening dialog for editing).
HTH,
Jan
I have noticed that in every theme I have examined from the Gallery and elsewhere, the Zone Names from the Theme Machine are used, sometimes when the Zone names make little sense.
Are there any internal dependencies that make use of those particular Zone names necessary or recommended.
Are there any consequences or difficulties introduced if those Zone names are changed when I create a new Theme?
In response to Piotr's answer:
So most of the Zone names are being recycled for convenience so that one custom theme can be based on a previous custom theme (both based on Theme Machine).
So is the zone-placement-admin-widget-zone-layer-assignment stuff tying up design efforts with a sort of convention tied to the Theme Machine zone names because of the configuration efforts imposed by the developer work patterns?
I notice that you and others are suggesting solutions based on code-over-convention to enable placing content programmatically, even using styles from another theme.
Does this mean that Orchard is moving toward a 'widget component' with a more well-rounded capability to live anywhere within the framework and compose itself nicely wherever we want to put it?
You can name your zone names whatever you find suitable without any consequences. You should only keep the Content one, as it's where Orchard puts content items' main content by default.
Zones specified in Theme.txt are used for widgets admin UI only - to display a list you can choose from.
If you rename/remove a zone that currently contains some widgets, those widgets will appear in the Widgets admin "orphaned" section so you can re-assign them to new zones later on.
Theme developers usually use the same zone names as in The Theme Machine purely for convenience. It's easier to switch themes as you don't have to move widgets around afterwards.
I'm working on a program that parses text and turns it into iCal events. I'm then using FullCalendar to display the information inside a google gadget.
I'm currently importing the .ics file into my google calendar, making that public, and then pointing fullCalendar at it.
However I'm trying to do accomplish without making the information public. Any ideas?
Alternatively, is there any other lightweight customizable javascript calendar that can interpret .iCal?
Ideally I would be able to just use a single day view/single week view and not an entire month view.
You never said if you using PHP, .NET or what.
So I will assume you use .NET just becuase i use it.
I use this nice DLL Library in .NET
DDay iCal
I use it to create iCals so that people can import to iphones,outlook etc. but briefly looking there is a way to serialize it as well, so you could use it anyway you need to.
And Google Calendars are not listed publicly any more because of private security. Only people with the link can access the gCal.. and your the only ones that knows it. If somebody wanted to get sensitive data then no matter what method you used it always has some vulnerably
I wish I had a better answer. I was doing the same thing (iCalendar format -> Google Calendar, public -> FullCalendar) but became frustrated with how slowly Google Calendar would update. So instead, I put the data into JSON format for FullCalendar.
So now, the site does (A) iCalendar format for distribution to people (they can add it to their own Google Calendar, iCal software, etc.), and also (2) JSON format for FullCalendar.
The advantage is that I can reformat the JSON "description" part to make it look better with QTip bubbles (html line breaks, css styling).
There is also jQuery iCalendar you should check it out.
And there is JSON to XML converter, it's very useful maybe it can help.
Both can work with any language, you should try them and see which
one is better for your specific calendar.
When using the core drupal 'Upload' module, I get a user-friendly way of uploading files to my website and providing a download link on the page.
But the page is formatted like this:
Attachment Size
Somefile.doc 13.37mb
Article contents here
And I would rather it was the other way around, showing the article contents before the attachments. I have explored how to do this and come up blank.
I'm using the 'Garland' theme if it makes a difference to how I can implement a solution.
You must be using some module that changed that order. Or had it in use. Since Drupal-core has no way to re-order fields, and Drupal core upload-field has hardcoded its position in the form and in the display.
However, if you want to re-order fields in Drupal nodes, there are several ways:
The first option would be to solve this in your theme. But since you are using a vanilla (core) theme, changing the code of that theme is out of the question.
The second option, just as valid, but a lot more disrupting, is to involve the "CCK (content construction kit)" module. A warning is in place: this module is both complex and powerfull. Over 90% of the Drupal sites use this module, but since it is large and heavy, it will make your project a lot more complex, debugging a lot harder and performance a potential problem. Use CCK only if you think it fits well in your entire project, not just for re-ordering a set of fields.
The third option is to write a simple module that re-orders fields.
With hook_form_alter(), you can change the appearance, workings and order of fields in any form, including the node forms.
With hook_nodeapi(), you can change the behaviour of any node on many stages, including when it gets displayed: to re-order fields.
As said above: you may have such a module (with hook_nodapi) re-ordering your output, since Drupal core upload has the weight of that field hardwired.
I have inherited a Drupal site on which (for some reason) there are two different content types for news: one for press releases and one for everything else. I would like to combine the two and use a taxonomy to categorize the press releases and other news types.
Is it even possible to do this? The site is using a number of modules, including Views and CCK, and I don't know how much a change like this would affect module data.
http://drupal.org/project/node_convert
The module linked above works extremely well for migrating nodes from one content type to another.
When you are done, you can then use VBO (http://drupal.org/project/views_bulk_operations) to mass manipulate the taxonomy changes you need.
Is it possible? Yes.
Is it easy? No.
To quote a well used phrase:
If it ain't broke, don't fix it.
You can get your site to work like you describe, and if you started with a clean site that you were going to build, it would be no problem. It's just a matter of choice. Now when you do have a database with views, content and other stuff, it wont be easy. You would have to:
Go through all the views, and set them up to use taxonomy and the 1 content type.
Migrate all the data into 1 content type. This might evolve setting up CCK for this content type to fit both, and take this into consideration when migrating the data.
It's possible the content types are used elsewhere, in custom modules, settings etc, these need to be tracked down and fixed as well.
So it's a lot of work with little/no gain.
Of course it's possible. The change won't necessarily be difficult if you've got a good understanding of how each content type is being used. You'll just need to be careful as it's a fundamental change.
If you think that the two different content types are not warranted and it is, in fact duplication of information then you could justify merging the two. Good house keeping!
You could phase out the unwanted content type over time and then when you're confident you've got it just right, build your self a merge module to move the old nodes into the new format. You could also build yourself test views and content types that you can dispose of later.
It may also help to install the devel module to get a programmatic overview of what your nodes look like. You shouldn't leave this module running on live sites as it effects performance.
Sometimes, there's a fair amount of crossover between content taxonomy and content types. It helps to ask yourself: What is a classification of an object and what's an attribute?
It is possible to change the content type of nodes.
The problem is if the content types use different CCK fields, which are present in a content type but not in the other. In such case, if you change the content type, those fields would not appear in the converted node; you should convert all those fields manually, or create a custom module to do that.