We're currently building a module which automatically create content type, which allow to quickly install content types on any Drupal platform, without having to manually create hundred of content types and fields. In our previous versions, we were manually creating node reference fields and it works great. Now, we want to create it using our module since we have to add those content types and fields on dozen of platforms already under production; creating manually the fields would be a crazy idea. Do we have to use the node reference API? We are close to being able create it but, in VIEWS, the node reference fields do not appears. It seems we missed something. We're trying to check in the CCK php files to understand how the CCK API is used (if we can create it in a form then, for sure, we can code it). Any idea? Which API and functions should we use? I would like to know the proper method on how to do this.
You should use features rather than write code to create content types. Take a site w/ all the types you need, export them to a feature, integrate that with your module, easy as pie!
Related
Im really newbie with drupal 7 and I want to tests things with it:
I want to build a form page that will get information from users.
for example workes that input FIRSTNAME, LASTNAME ID, PHONENUMBER and etc.. after that they will submit and it will enter to the workers db.
as I mention im really newbie with drupal.
so first of all, where do I start? is form api is the best way to do it?
secondly, the system create the workers db or I need to create a new db and table?
Drupal has examples module that has lots of example for developers you can install it and check code how it, i think form_example it suite for you.
Why don't you use the standard Drupal Content Types. You can create a content type named worker and the have your workers add their info as you wanted.
To create your custom content type:
You can create your own custom content types by going to Menu >
Structure > Content types > Add content type
(admin/structure/types/add). You might do this as a way to organize
your content. For instance, you might have "Info" and "News flash" as
two simple content types on your site, rather than just using
"Article" for both.
Another alternative to use webform contributed module. It will give you the ability to create a from with fields of your choice.
Webform also provides few features out of the box you might need to use. Like; Limiting number of submissions and unique fields.
Finally, I'd suggest you can read Drupal concepts.
I want to create an online Arabic-Hebrew Dictionary for one of my clients and this is my first experience in Drupal Module Development. If I were to create the Dictionary in custom PHP and MySQL, I would create a number of database tables and do my queries accordingly.
I know that there is a built-in content type in Drupal 7, should I use it or create my own content type, If I should create my own content type, how can I do it ?
Thanks!
The built in content type will give you a Title and a Body, you can also use taxonomies in order to get more specific queries.
Creating your own content type will depend on your site structure. If the above is sufficient, simply use or modify the built in content types, otherwise create your own.
My advice would be for you to experiment with Drupal, watch various tutorials, then decide on the structure that would be best fit your requirements.
Your question is very vague, there are a lot of resources out there for Drupal beginners, you'll get a more detailed answer by checking tutorials first.
I believe that it depends. It generally is better to build upon the existing content types as much as you can. But if you determine that it would be too awkward/inconvenient to build upon the pre-existing content types in order to get the best solution to your problem, then you should programmatically create your own content type in your module.
Whichever path you choose, make sure that you properly document your content type structure, so that whenever you or someone else has to use that module, they will know exactly what each field is being used for, any dependencies, etc.
It may sound 'weird' but I need to have a view that lists all the content types I have.
For example i have two content types : contenttypeA, contenttypeB
I want to create a view that just displays the two content types (and show number of items of that type, but that can be done later).
For now what I did is add one content of each content type and list them but only show the 'node type'; it works well if there's at least one content but I want to display even without any content of that content type.
Any idea ?
Introducing the node_type table to Views requires a custom module and some Views API knowledge however http://drupal.org/node/1001222 will give you a head start.
Use a Customfield: PHP code field and custom code the whole thing with PHP. This is provided by the Views Custom Field module.
Use the Table Wizard module to make the node_type table available to views. You may need to use the Data module as well since they say that all future development is going there.
Expose the node_type table yourself by writing a custom module using the Views API as suggested by chx.
Number one is the quick and dirty way, but number 2 might be a little more manageable, but I am not completely sure it will do everything you want. If you do number 3 make sure you contribute back to the community by putting your module on drupal.org.
There is no native functionality in Views to do that. You can write a static page or (overkill) a module that provide a "system"-like type similar to Views Watchdog.
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.
The Content Construction Kit (CCK) is one of the most useful Drupal modules. It allows you to easily add custom fields to a content type.
However, these new fields are created through Drupal itself and stored in the database. This means that if you change a CCK field in your development environment you need to manually make the same change in your test and production environments.
Worse, there's no simple way to determine if your environments have gotten out of sync. So if you ever inadvertantly mess up or omit a change as you put it into test or production you may never realise.
I'm looking for a technique that allows me to export CCK field definitions that supports:
Importing into new environments (obviously)
Creating new fields
Ideally the export would also support:
Diffing
Modification of existing fields
Deletion of existing fields
Some kind of conflict resolution in situations where data clashes with field changes
The simpler and more repeatable the solution the better. I would like to avoid custom scripting or GUI automation unless there is a very clean way to do this.
Are you aware of the Content Copy module that is part of the standard cck package? It offers export/import functionality for fields and whole content types to some extent.
It does not offer diffing by itself, and I'm not sure about how well it does modifications of already existing fields, but it helps a lot for moving new fields and/or content types.
Also, you can save the output of exports from different instances and diff them locally, which gives you a pretty good overview of changes (especially revealing 'out of sync' situations quickly).
After enabling, check the new export and import tabs on top of '/admin/content/types'.
It is not that mature yet but the features module will allow you to do this. It packages up CCK fields (among other things) into drupal modules which you can distribute.
I personally use the Node Export module + Node Export File module (included, for CCK /image fields).
The entire node is exported into a textarea, as an associative array. The import form is similar: you paste the node array into a textarea. These processes are implemented as node operations, so they can be done in bulk (on the /admin/content/node page, or in your custom deployment module).
The benefit of this process is that you can modify the node data in transit.
Using a text editor, you can change the content type, title, add/remove/modify fields, whatever you want. Using a text editor with good find/replace, you can mass-edit hundreds of nodes. Since you have text, you can probably do all the things on your requirements list using existing tools or quickie scripts.