How can I extend an existing module without modifying it? Actually its a contributed module, so I don't want to hack it. But I want to alter and add certain features to it.
I'm new to drupal and as I read tutorials about it, I keep hearing one thing again and again - Don't hack the core... and I believe the same applies for modules too.
Avoid hacking or forking the module if at all possible. Hacking the module gives you a lesser variety of the "hacking core" pain, and forking the module (without a distinctly superior architecture and feature set.) just muddies the module water further- making it even more difficult for sitebuilders to make an effective decision about what to use.
The best solutions are:
Use any API provided by the module. Sometimes there are functions you can use as API calls that are not necessarily intended that way.
Create the additional functionality and submit a patch to the module issue queue, so others may benefit from your work, and so you may benefit from security audits without much sweat.
Not always, but often you can go far creating a custom module that implements hook_form_alter and adds a submit handler that leads back to your module for processing.
Found a very good post about extending a module in drupal. Essential parts:
If the module uses code for a page callback that you want to change, change the page callback with hook_menu_alter().
If the module implements a theme function you want to alter, change the function associated with hook_theme_registry_alter(). In alternative, if it is sufficient to change the variables the theme function gets, then you can implement the preprocess function for that theme function (e.g. hook_preprocess_rdf_metadata() for theme_rdf_metadata(), and change the variables that theme function will get.
If the module executes an SQL query using db_select(), and assigns a tag to the query, change the executed query with hook_query_alter().
If the module implements a hook you don't want it is executed, you can implement hook_module_implements_alter() to avoid it is executed.
If the module implements an alter hook (e.g. hook_page_alter()), and you want to change what that hook altered, implement the same alter hook, being sure it is executed after the one implemented from that module.
In the case the function you want to alter is not a hook, then:
Check that function is using hooks implemented from other module. For example, node_save() invokes hook_node_presave(); if I would want to change the "changed" property of the node, I don't hack node_save(), but I rather implement hook_node_presave() to alter it.
Check that function is referenced/used from a hook; in that case, you can do something for that hook, as I previously described.
If anything I said until now doesn't apply, then it is better to create a custom module, and use the code of the other module to create it. I would also try asking a feature request for the existing module, hoping the feature is implemented.
Hacking a third-party module is never a good idea, especially because automatic updates of the module (via the Update Manager, or Drush) would not anymore possible for that module.
What module is it? Some modules provide APIs that you can extend by writing a module of your own. There are tons of modules that "extend" Views by building off of the Views API. If the module you want to extend doesn't have a good API, you can always fork it to make a version that meets your needs. Maybe it will help someone else too.
Even if we need to use some functionality we can do it in the following manner.
We need to copy the function from the module and we can paster the function in your template.php file. Than you can make chanages on that function accordingly.
To change the form shown by the module, you can simply create a module that implements hook_form_alter() or hook_form_FORM_ID_alter(). Most of the times, when you want to modify how a module behave, you also need to change the settings form it uses (or any other form).
Related
Let's start with basic thing, simple example is Yii. It has such thing as widgets. Standalone, configurable and callable from any place we want classes. And I'm wondering can symfony2 has the same? What it will be? Controller in bundle? Action simple (method)? Widget (twig) with parameters?
In Yii we create class (of widget), standalone, describe it and use (by calling in template). How will it look like in symfony2?
Simple example 'i want create menu navigation using widget, where it will construct html by user roles'.
Symfony doesn't provide such a feature however you can make them yourself. They are few ways of doing it.
I'll just admit that we are talking about widgets that could do backend work (i.e. get data from DB, call an API, etc.).
1 - The scalable way
The use of the render tag in Twig which allows you to call a controller action from a template. It's scalable because you could use esi tags with Varnish (you can also implement your own caching profiles).
As a bonus, the profiler will show details about the specific render calls in the timeline (it will look like a subset of the entire request).
2 - Include a template
The included template gathers the data through a Twig function call. By experience, it's a bit faster than the first solution however it's not easily scalable.
3 - Render through a custom TwigExtension
The twig function will get the data and call the renderView method of the template service. If you are planning on doing this, you probably want to use the first method.
Conclusion
If you have a big website with modules/widgets that gets a lot of traffic (or "hit"): use the first solution.
If you have a small website with no support for caching: use the second solution. You'd use this solution if the module/widget is super light.
If you are thinking about the third solution... it's probably a good idea to use the first solution.
Personally, I'll always try to use the first solution and try to boost the performance one way or another. The render call in Twig has been significantly improved since the last versions of Symfony2.
Hopefully, my answer will provide you some guidelines.
I want users to be able to submit nodes and comments via AJAX. I also want to do some fairly extensive customization of the node and comment forms.
I've spent time looking through documentation and code examples for Drupal 7's Form API and Ajax framework, but I find it very complex. Therefore, I simply want to create my own form in HTML and use my own JavaScript code to submit it via Ajax. I'll also set up a specific URL for processing these Ajax requests, which will ultimately call node_save() or comment_save() when appropriate.
What are the downsides to doing it this way as opposed to going through the Form API and Ajax framework? I'm not creating modules for contribution to the community. Everything is just for my own site.
Technically, yes you can do this with no ill effects. There have been times where i have had to import data from feeds and have used node_save manually.
What you are missing out on is the flexibility that drupal offers. For example, want to add a new checkbox to the form to indicate a featured item? Now you have to manually update the form to add the field and update the submit handler to save the data. Had you used drupal's system it would of been auto-populated for you.
Further on flexibility, say for example, you decide you want to add a CAPTCHA field to your form. All you would have to do is enable the CAPTCHA module and specify the form you want it on and it would be done for you. There are a bunch of 3rd party modules that let you do things like this.
Drupals form system also lets you add more complicated items such as date selectors, or even managed file uploads, which can save you a lot of time once you are familiar with the API.
If your looking just to get the project done and not spend time learning something new, sure you can do it all manually. I can promise you any drupal developer that looks at your code in the future will have a very low opinion of your work. Depending on your situation this may or may not be important. But really the biggest thing you are missing out on is ease of maintenance and flexibility.
So just to recap:
pros:
it will work
quick and easy
comfortable
cons:
loss of flexibility
harder to maintain
inability to take advantage of drupals form widgets / helpers
inability to take advantage of 3rd party modules
shame from other developers
Lack of sleep from dirty feeling
eternal damnation
The usual argument would be about portability I guess, but if you're not going to be porting these modules to another Drupal site then I guess that falls down.
The same can be said for offering other modules the chance to alter your form based on some global/inherited setting, but again if you really don't want/need this functionality then it can't really be used as an argument against.
The one thing you will lose out on is the built in Cross-Site Request Forgery protection. As long as you're rolling your own version of that, though, you should be ok.
If you plan to use Drupal a lot I'd recommend getting used to the FAPI though...after a while it actually becomes a lot easier to use the FAPI than write out custom HTML.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm trying to write out a list of key Drupal competencies, mainly so I can confirm what I know, don't know and don't know I don't know. (Thanks D. Rumsfeld for that quote!)
I think some of these are really broad, for instance there's quite a difference between making a functional theme and creating a theme with good SEO, load times and so on, but I'm hoping you could assume that a half decent web developer would look after that anyway.
Just interested to see what people here feel is also important. I've edited the suggestions so far into this list.
Languages
PHP
MYSQL
Query
Drupal Skills
Research and install modules to meet project requirements
Configure the basic modules and core settings to get a site running
Drush command line tool
Create a custom Theme from scratch which validates with good HTML/CSS.
Able to customise forms, core, themes without altering core files but by using template.php or custom modules.
Can make forms from scratch using the API - with validation and posting back to the DB/email
Can create custom modules from scratch utilising core hooks and module hooks.
Be involved with the community, understand the naming conventions, CVS system and ideally have submitted some code or revisions.
Modules
It's not easy to make a must know module list, as not only is the modules you use very dependent on the site, but also how you use them. However the following are widely used:
Views
Know how to make basic views and blocks.
Know how to make more complex views with relationships and terms.
Know how to use hook_views_query_alter, to make complex queries.
Know how to use hook_views_default_views, to create specific views.
CCK
Know how to setup content - what field types to use.
Know how to create your own field_formatters - the foundation for theming CCK fields.
Hooks
The most important hooks to learn, to create a basic module are probably:
hook_form_alter() - change forms without changing code.
hook_menu()
hook_theme()
hook_nodeapi() - almost anything regarding nodes
hook_schema() - create tables
hook_install() / hook_uninstall() - create tables and clean up.
hook_perm() - when you need special access control.
hook_init() - things to want always to happen.
hook_user() - if you need to tap into user actions or modify the user object.
I good understanding of client-server architecture, how servers and browsers works. And knowledge of php and mysql, templates engines. And of course, you should also read Drupal documentations.
Able to create a custom Theme from scratch which validates with good HTML/CSS and also pays attention to usability and accessibility. (Whilst still looking kick-ass).
You usually don't want to create themes from scratch but from a starter theme like Zen instead.
For Drupal you will need:
PHP, it's a PHP framework, so to really understand and use it, you need to understand PHP.
SQL, the list of SQL serves that Drupal can use is growing, but you will need to understand * SQL, relational database and how to setup some basic architecture.
Javascript (and jQuery). Drupal uses the jQuery js library, so it will be a lot easier if you not only, know how yo use javascript, but also understand how to use jQuery and some of it concepts.
The hook system and how you can alter Drupal core and modules implementing hooks.
The naming convention for hooks, theme functions etc.
Modules
It's not easy to make a must know module list, as not only is the modules you use very dependent on the site, but also how you use them. The two top modules in Drupal is.
Views
Know how to make basic views and blocks.
Know how to make more complex views with relationships and terms.
Know how to use hook_views_query_alter, to make complex queries.
Know how to use hook_views_default_views, to create specific views.
CCK
Know how to setup content - what field types to use.
Know how to create your own field_formatters - the foundation for theming CCK fields.
Another module that I find very powerfull once mastered is Panels. It allows you to do a lot of complex and difficult things with very little and simple code. There is a lot of hooks you need to learn, and not much documentation. But once you understand Panels, you find that you time has been well spent.
Hooks
The most important hooks to learn, to create a basic module is probably:
hook_form_alter() - change forms without changing code.
hook_menu()
hook_theme()
hook_nodeapi() - almost anything regarding nodes
hook_schema() - create tables
hook_install() / hook_uninstall() - create tables and clean up.
hook_perm() - when you need special access control.
hook_init() - things to want always to happen.
hook_user() - if you need to tap into user actions or modify the user object.
You don't need to use all of these hooks all of the time, but they are some of the most used ones.
Great list so far! Some others for consideration:
Ability to use Drush to update or setup a site
Strong understanding of good best practices configuration for performance, security and SEO of a Drupal site (think launch checklists)
Having submitted a module to Drupal.org (however simple) or submitted a patch (the process of getting a CVS account and getting your first code in is instructive to the community and to standards)
You don't need SEO skills for templates, drupal usually helps with SEO alot. Ofcourse a developer who will slice a design must know that all headings must be done with h1,h2,h3,h4 tags. that's really basic one. everything all is up to drupal..
as for my opinion to be a drupal "developer", you need some very basic skills in PHP. Because drupal is really written without object-oriented programing, and without DESIGN PATTERNS, so these are two things is really makes you a programmer.. without them it just [sorry for this word] bullshit not a programming.
I think anybody can install drupal or wordpress or some cms-made-simple, systems if you have at least once connected to ftp in your life... to develop plugins for them is a requires basic skills of php. Ofcourse if you'll find skillfull developer then he will know oop basic, and will write plugins with OOP and that code will be really NiCE! =)
Being able to edit existing functionality (core or module) without touching the core or module and knowing whether to put it in template or a custom module.
As we anything web related these days, you really must have a good understanding of the HTTP protocol. You also need a good understanding of JavaScript, the DOM, CSS and HTML5. Knowing a bit of jQuery is not enough for a developer, you need to understand what your are doing with the DOM, HTML5 APIs and CSS in order to build features and behaviours into the browser. You also need to understand the Drupal JavaScript APIs, both on the server side (hook_library(), #attached, etc.) and the client side (Drupal.behaviors, etc.)
You also need to known the various APIs of Drupal. The Form API is not the only one. You need to understand the Menu system (page, access, title and delivery callbacks, how to pass parameters to them, etc.), the Queue API for asynchronous operations, Batch API for long running operations, Entities and Field APIs for user editable structured data, Theme API and Render Arrays for anything presentation, Cache API, Schema and Database APIs, File API, Cache API and the Localization API.
Many long nights spent on my site, and now I've started doing all sorts of security checks and stumbled upon the following:
www.mysite.com/node
That shows the latest x nodes that a user has access to. I DON't want this view visible to users. And I certainly don't want any other views similar to this available. So, my questions are:
How do I disable this view?
Are there other hidden views that I'm not aware of that an anonymous user can use to access several nodes at once?
You want to use hook_menu_alter() in a custom module to reroute what happens when someone tries to load the page at /node. There are two approaches.
First, you could give an unequivocal access denied:
function custom_module_menu_alter(&$items) {
$items['node']['access callback'] = FALSE;
}
Second, you could reroute the page to one of your choice:
function custom_module_menu_alter(&$items) {
$items['node']['page callback'] = 'custom_module_new_page_content';
}
function custom_module_new_page_content() {
return 'Go away!';
}
Other Listings
If you are worried about listings where users have access, the search results and tracker are the only other places that I can recall.
This comment provides the logic to unset whatever you want from the search results using a custom module.
Unfortunately the Tracker is not particularly customizable without direct hacks. Your best bet is to use one of the tracker replacements in contrib, or easier yet, modify the Tracker replacement that is packaged with the Views module.
EDIT: Clarification- you could also disable the Tracker module form the optional "core" modules. However, it is a very useful functionality so you might want to keep it around in some form.
As for disabling paths you found, I'd second Graysides suggestion of using hook_menu_alter to adjust the access callback.
As for other 'hidden' views, this depends a lot on the modules you use, as many modules add some default 'views' (in the sense of overview pages, not necessarily views module views). So instead of trying to find them indirectly here, I'd suggest to take a look at the menu_router table of your Drupal database. There you'll find all paths currently used by your instance (internal paths, not aliases, but all aliases map to an internal one).
One relatively simple way to do this that works is to turn on the Path module under core and alias /node to something else like /node/1 or whatever ..
Not sure about other urls that get you things you don't wanna see... i would think this technique would work for any you come across
function modulename_menu_alter(&$items) {
$items['node']['page callback'] = 'drupal_not_found';
}
Source: http://drupal.org/node/500296#comment-3532630
the "node" view is the default frontpage view. So it is usually the same tha appear on you're frontpage.
I Am new to drupal I need to customize core functionality like register module and event module.please share you thought / sample code / sample website for get the clarification over my issue
Thanks in advance
Balaji
From what you posted in the comment to creejayoz answer, it seems like what you are after is not using hook_form_alter, but something in the line of what the profile module does. It's part of drupal core, and with it you can add extra fields to the user like first and last name. There are also more advanced modules that you can use instead, but it seems like you wont need it. Using the profile module will also be a lot quicker and easier than using hook_form_alter as you wont need to create a db table make SQL and such to the save the data.
You can use hook_form_alter to heavily modify the way Drupal's registration works, by modifying the form's fields, adding extra validation/submit functions, etc. It's difficult to give more detail without knowing what you're wanting to do.