I am new to the nopcommerce development. One thing I noticed about in the first place is that, to custom the system(adding fields to category, product), I must edit the official code. I am not sure with this approach, especially when I think about the upgrading in the future. But seems this is the only way? Can anyone share with me your points on this topic? Thanks.
Short answer: not a good idea to change base code.
And also it depends on how you change.
Some tips on changing base code
make sure the signature of base methods remains the same. Else this will break lots of plugins.
create new method if you need to change signature of base method.
And last, you should really try writing plugins. If you see the nopcommerce code plugins are injected everywhere you would need. I personally find it cleaner and easier(after a phase) to write code when creating plugin.
Related
I have a specific theme which I apply to my html and now instead of editing it everything I create view. I want to edit the html helper methods and all all my necessary classes and id information can be put in one place.
How do i do this?
Do I just create a new custom one or is it easier to edit one that is already there? I do plan to add some ones that are not there.
I have googled abit but all the answerers I found give specific code to their problem. I dont even know which folder to put my classes in? In a book im reading about mvc it explains custom model template, but i dont think that is exactly what im looking for?
Even a basic example will be great.
Do I just create a new custom one or is it easier to edit one that is
already there? I do plan to add some ones that are not there.
I would say creating a custom one would be fast and simple. But if you still want to give a try by enhancing existing one, than you can get the source code of System.Web.Mvc for CodePlex, and make your necessary modifications and build it, reference it and use it in your project.
How to add new language in Plone 4.2? I looked at the code on plone.i18n.locales.languages.py. The languages is hard coded inside the code. Anyway we can extend the language list without modified the core code. Any plug in, may be? Thanks.
Benefit from the advantages of opensource and contribute it right to the core.
The i18n-team will be happy to help you further, just leave a post in the forum:
http://plone.org/support/forums/i18n
I starting working with WordPress as a CMS, now that the V3 makes it way easier to manage taxonomies and custom post types. My work is mostly focused on developing plugins and themes.
My biggest plugin does some admin stuff (add admin menu items and the related pages and features), but also does some importing and exporting, and hooks some of the base post processing treatments ("when a new post is created").
My biggest theme is pretty small, and all it does is display custom posts in a custom way.
After a few weeks of work, I have several thousands of LoC, and it's getting harder and harder to dig into it. Which leads me to the following question: How do you organize your WP plugins code? And what about your WP themes code?
several thousands of LoC
That's pretty epic! I've always found the beauty of WP is that I can, as jQuery put it;
Write less, do more!
You might be much better off using Pods CMS alongside WP to cut down your code.
This is how we structure client deployments that include themes, third-party plugins, and custom code.
wp-content/plugins only contains third-party plugins, no code in here is modified, and the site should not be deadlined by any of these plugins being disabled / removed.
wp-content/themes should contain the code related to presentation of the front-end. The trick is not not overload the theme (functions.php and other theme-related files) with code not directly related to presentation.
mu-plugins/ contains all of your implementation-specific business logic. Things in here should never be disabled, and are required for operations.
That is avery brief summary, but in a nutshell that is the logical compartmentalization of code that we've found to be most failure proof.
Why not to split plugin into several files by function? The same goes to themes. Any problem you have with that?
There are basically three ways you can do this: prefixed functions, with require_once's including files by functionality, which is quite common.
The other "right" way that's touted a lot is having one giant class with all your plugin code in it. While keeping things nice, as you said, once that file gets into the thousands of lines of code, you're screwed for manageability.
The way I like to do it is a way coming from my C# background - have one main plugin class, and other "worker" classes (you can put them in a namespace to keep classnames short). For example, have a class dedicated to the admin section (it can have its own little "subclasses" too, say one for each page). It'll take a while to refactor all this code into the different classes and files, but it'll be worth it - it'll be much easier to keep track of everything, as well as for example getting people to work on the codebase together. It also forces you to think more of how your application all fits in together, which lends to better thought out code.
I'm actually writing an article series about this, outlining the three different methods. You can take a look at the first instalment here. There are two more coming in the following weeks.
Hope I helped!
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.
For creating wordpress themes, people usually follow one of these two methods
Design Mockup in photoshop or similar tool and code the HTML & CSS from the scratch
Choose a base theme and design the mockup keeping the base theme in mind and code on the selected base theme.
Which is the better way of these (or anything other than these) on tackling the Wordpress theme creation?
It depends on what you're trying to accomplish. I lean and develop using Option 1, with using option 2 as a way to glean ideas from.
The main reason is that the photoshop mock-up, no matter how close you ask the designer to follow a existing template, "usually" is different in some fashion, so that by the time you get into the middle of the theme you find that the existing template you could modify doesn't accomplish everything that the client is asking for (unless the client is a relative, in which case you could say too bad).
The other reason is call scope creep. Meaning that the original scope that was presented has now grown past your theme. You'll then have to ask yourself if you can dive into someone elses code and figure out what they were trying to do and then see if you can hack it up enough to fulfill you clients new requirements or if you're better of developing from scratch and then when scope creep comes up, you know right where to go/do in order to meet their requirements.
Anyways, something to think about.
It really depends on what your company/client requires. If they have specific requirements that cannot easily be met with a theme, you'll probably be better with option #1. If they are asking for a design submission, and are leaving the implementation/design up to you, go with option #2.
Some of the premium wordpress themes out there are quite good. Note that for either tool you'll be doing a mockup in Photoshop, so start with that and see what your company/client thinks.
You'd probably want to use an existing theme as a base for a new theme, or at least as a reference, for knowing which Wordpress Codex functions to call to retrieve data to use in your theme.
The HTML/CSS design is only half the solution - you still need to retrieve the data from WP to show.
Use Sandbox to start your theme with, it is free and it gives you many classes to do a lot of the design tricks you see is great wordpress themes.
http://www.plaintxt.org/themes/sandbox/
Another great theme to start from would be Thesis:
http://diythemes.com/thesis/
I always start from a theme that allows me to do things easier in the long run.
I always start out with a Naked theme (like Starkers, by Elliot Jay Stocks), and otherwise build everything from scratch.
If you want to save time, or are not (and don't care to become) very familiar with Wordpress PHP logic, then I'd start with an existing theme.