I want to modify a javascript file bundled in a drupal contributed module a little bit, for example changing a specific #id to css .class etc. As far as i know it's not good to modify source code of that module for upgrade reason. So, can you pls teach me how to do that the best way?
If you can accomplish what you want in a separate .css file, that would be best.
If it's an improvement that would enhance the module, simply make the modification and submit the patch back to the community. The drupal site has full details on how to create a patch.
If the patch is very specific, see if there's a way to make it generic so that you can submit it.
If all else fails, and you have to make the change, COMMENT. It's also good to create a patch file with the change and save it outside of the contrib module directory. The whole reason to NOT make changes is that updates become a real pain. If you document every change you make, and feel confident that you can re-apply them, then you should be OK.
Related
I've been trying to figure out how to make the current SlickUpload 6.1.7 play nice in a form that does not require someone to include files. We want it to be optional. This form is for people to contact us, and we want to give them the option to include attachments, just not require it. It works if you upload a file, however the form will not submit, if you do not upload any file.
We are trying to use the Ajax version with Memory stream, but the 'AspNetAjaxCs-VS2010' sample code is not helping much... the documentation is sparse, and the samples have little constancy between them, making it hard to understand how exactly it all works. (at least for me) The fact that they got bought out, and the new owner company pretty much ignores people unless they are paying for it, is not cool.
Any ideas?
You could use a div to detect a drop inside your page. That way you could only activate it when the user really need it, or whenever the using actually select something for uploading, like a trigger.
I'm not sure I understand your question, but if so, it sounds like you already have a form that you want to use SlickUpload with to upload files IF there are files to be uploaded. Are you using the CustomUploadStreamProvider form?
I've been wonder for some time what the best practice is for modifying a plugin created by a WordPress user?
For example there are a couple lines of code I want to change within the Contact Form 7 plugin. The function is called function wpcf7_ajax_json_echo() and is located in:
wp-content > plugins > contact-form-7 > includes > controller.php
Of course I could just change the code right in that file and be done, but then I'm out of luck when I want to update that plugin as my modifications will probably get written over.
I know I should be making this happen via my functions.php file, but I'm not sure how to go about achieving this. Also, that particular function is 100+ lines of code and I'm guessing I don't want to overwrite that whole function, because there is a good chance the author of the plugin may choose to update something in that function in the future.
Does anyone know the cleanest way for me to modify a few lines within that function via my functions.php file?
Thank you!
I do not recommend changing the core. However, you are in a bit of a pickle.
You can:
Update the function code directly in the plugin
Copy the current function code from the plugin and override it in functions.php
In the end, you still run into the same problem - future compatibility.
Either:
The update will overwrite your plugin changes.
Your function overwrites the plugin changes.
So, as much as I don't want to say it, I'd update the plugin directly. At least then when you upgrade, you'll know pretty quick that your change is missing. Furthermore, it's possible the plugin updates will include your change.
You could use SVN if you wanted to maintain forwards compatibility (and your host has SVN available), whilst being able to keep your own changes.
Each plugin that's on the Plugin Directory has to have an SVN repo (that's how the Directory knows if there are updates). Here's the CF7 repo.
Checkout the trunk to your /plugins/ directory inside a folder like /custom-contact-form-7/. Alter the wp-contact-form-7.php file to give it a unique name, and make the changes you want to make to customise it.
To get new updates you can just svn up to get them, and they'll merge with your changes. Though, you may have to clean up merge conflicts sometimes.
Version Control with Subversion is the place everyone starts to learn SVN, if you need it. There's also a Github repo now, if you'd like to fork that.
I definitely think you should add your updates to functions.php or to a custom plugin. It's a hassle right now, but MUCH less hassle every time you upgrade the plugin.
You'll always have to reference the changes made in updates no matter what. Even if you're able to extend the functionality without copying this file, you'll have to at least check and make sure your changes still work. And WinDiff/BBEdit's compare will make quick work of that.
So my first suggestion is to override that function.
Second suggestion:
I noticed there's some extensions (a, b, c) to this plugin; perhaps you can find out how they made their extensions and use those details to make your own. Well, that's like suggesting you make a new house in order to fix the dripping faucet, but it's an idea.
How do you upload an image with a custom post type in Wordpress without hacking at core files or injecting that multipart thing with jQuery?
The answer depends on what you are going to use to manage those images once they are uploaded. If the upload-and-create-custom-post is all you care about, then you could do it with a trivial plugin.
However, if you want to do the whole management enchilada, then the simplest thing might be to copy the code in wp-admin/upload.php and wp-admin/includes/template.php and make your own changes to that. There are very few action/filter hooks in this code and some of the comments indicate that it goes way, way back. In upload.php there are several SQL statements that have post_type='attachment' hardwired. Changing those should be straightforward. Mercifully, you will probably have only a few changes to make in template.php. As the comment at the top of that file says, "A Big Mess. Also some neat functions that are nicely written." So true.
The one thing you must not do is hack the core files themselves. WP's one-click upgrade is critical to their security fixes.
I'm looking to see if anyone has any resources or tips for developing basic Drupal modules faster? Have you come up with anything to make your Module development faster?
The Drupal module documentation is kinda hard to understand and pretty massive. I'm wondering if anyone has simplified it and given techniques/tips for getting specific things done quickly. I'm currently looking for Drupal 6 and 7. Any help saving time will be greatly appreciated :-)
In general, I'd recommend picking up a copy of the Productive Programmer. There's nothing earth shattering in it, but there are lots of small tips that can increase your productivity incrementally.
For Drupal specifically, Pro Drupal Development and Pro Drupal 7 Development, though not focused strictly on speed of development, are indispensable.
Beyond that...
in the first place, if you don't have to, Don't Write Code
get familiar with the most commonly used hooks
learn to use Drush and Drush Make
learn to use Devel and Theme Developer modules
use the Schema module to generate your module's schema code, based on an existing table
use the Data module (+ this patch) to generate the code to expose your module's tables to Views
use the Form Builder module to generate form code
use Coder to learn the Drupal coding standards, which will help others help you
set up "quick searches" to allow you to quickly search api.drupal.org
learn the shortcuts in your IDE or text editor (I like Netbeans partially because of the Drupal plugin); print out a good cheatsheet
learn to use version control effectively
Well, there really no fast track to it. If you understand the Drupal API regarding module development (install, menus, blocks, forms, etc) you will grasp it. The hardest part I remember was wrapping my head around the menu system.
One thing that helped was taking simple modules and seeing how they worked, and problem solving my own solutions. Reading Pro Drupal Development helps too.
You basically need to have an understanding where to look (API function, hook, system... ) when you want to do X. There is really no need to memorize all hooks/functions in detail with all the arguments and stuff. That's something you can easily look up. Especially if you're using an IDE with I suggest (Using Netbeans myself).
Especially when you're altering stuff, try to develop some techniques to quickly figure out what code is responsible for the stuff you want to change. One example is to look at the hook_menu() definition of the module that does it and then check out the page callback and skim through the code. Things to look up: Are there hooks you can use, is it a form (if yes, what is the form_id, how is the form structured) and so on.
The best and maybe only way to get there (knowing where too look) is exercise. Every time you do something, you'll be faster the next time when you have to do something similar. I think what also helps is working on core/contrib modules together with others. You not only get to learn these modules better, you also learn how to read and understand code written by others better and you improve your own coding style.
Try to utilize proven, generic "building block" modules like Views, Flags, Panels, CCK/Field and so on. Then, the heavy lifting is done by these modules and you only need to provide the glue code to properly integrate them with your site. Might take a bit more time the first time you use these modules but you will likely save a lot time after that.
That having said, I'm not sure if the goal should be to build modules fast. I'd say the goal is to build modules better. Try to make them generic, secure, flexible, theme-able and so on with the goal to re-use these modules on the next site your building, when you need something similar.
The majority of basic drupal module development is copy and paste. If you use textmate, the Drupal bundle for it allows you to build up key bits of modules (menus, theming functions etc) just by point and click (as it contains most of the necessary code snippets; you just fill in your info).
Following the module building tutorials is good too; the truth is, if you spent 3 or 4 weeks doing it day in day out, and you already have some background in coding, you'll be just fine.
Gedit for Drupal will preconfigure the very good Gedit editor/IDE for you.
For example, a new module: create an empty module file mymodule.example. Enter that file.
module<tab> And it expands into a full, predefined module.
Or in any module: hook<tab> to see a list of available hooks. Choose e.g. menu<tab> and it expands to a full predefined hook_menu. With <tab> you can walk trough all the variable parts in that new hook, to fill in the details.
Drupal.rb Has a.o. a $ drupal generate module "modulename" command that opens an interactive shell, wich allows building scaffolds for modules. The templates from which these scaffolds are built, are overridable.
I had an idea for "cheap" version control of the css of one of my sites, but am thinking it may not be a good idea. Thought I'd throw it out here in case someone has a similar idea that works better (besides real svn, etc.)
My thought was to create a main css file like "sitename.css" then use #import inside this file to connect to the most recent file with updates. I'd name these imported files by date, eg: 20101222_css.css so I'd know when the last update was applied. When I have a change, I could make my edits, drop the update in the respective location, change the #import to the new file, and viola... updated on the site.
After reading about issues with #import, such as it loading AFTER the page finishes, I'm not too keen on this now.
Any ideas of a way to implement something similar without a full blown system? I do a lot of small project work for various people and thought this method may be a simple way to keep track of things.
Thanks for any ideas/suggestions.
Your idea would add additional page loads to your site for no good reason, which will be a performance hit. It would also expose your versioning to the outside world. And as you say it will suffer from slow loading speeds due to the way #import works.
But the real down-side of this technique is that it only works for CSS files. You haven't solved the problem for any other files on your site.
You seem to think it would be simpler to use than a real SVN setup, but if you end up coming up with different techniques like this for every type of file on your site, you could easily end up giving yourself more headaches than you solve.
SVN is actually quite straightforward to use. With a good GUI (try TortoiseSVN), it's so easy you almost forget its there. Seriously, use SVN. There's no need to come up with 'clever' alternatives.
Its not a good idea, especially if you push this into production. If you want "cheap" version control, download VisualSVN. Its free.
The guys at Yahoo use a technique that reminds me of what you describe:
<link rel="stylesheet" type="text/css" href="http://l.yimg.com/a/combo?arc/yui/reset_2.6.7.css&arc/yui/fonts_2.6.4.css&[....]/subfooter_0.0.12.css" />
It makes sense for them because it's a caching tecnique. They set HTTP headers so stuff never expires: if you load the site one year later and you haven't removed your browser's cache, you shouldn't need to fetch again any of the files that haven't changed.
However, it's by no means a sensible version control system. You already have a good bunch of real version control systems out there!