I'm new to working with open source projects and I'm currently looking into OpenCart specifically. Sorry if this question is a bit dumb but how much can I change the code to customize my needs?
Lets say I want to make the telephone field not required. Can I simply remove the if statement in the controller?
Or if I would like to add a new field house_nr to the checkout; can I just create the database field and alter the code to make it work?
The reason I ask: Wont that break the code again when I update to a new version? What is best practice here? Should I keep a document of every file I altered so I can do it again in a big update?
Modifying the core will 100% break when upgrading, but you are free to do so. As always backup often, cos a reinstall will destroy anything else you did.
Use vqmod and custom templates instead. TRicky to work out at first, but you will be very thankfull down the line. Google them to resarch both.
Related
Can someone please help me with this issue? Also please kindly explain me the instructions step to step cause I have less experience and understanding regarding Programming things. Thanks again
About all we can tell from that message is that the .snd widget (“widget” is the name for a window or control component in the Tk toolkit, which is the primary GUI library for Tcl) was not existing at the point where that pack configure command was called. Except we've got a bit more context from the stack trace: it's in a procedure called CreateWidgets that was called from another procedure called CreateGUI so it's almost certainly doing widget creation and setup (pack configure is a reasonable setup action).
Given that, the problem is probably either that the code is asking to work with a widget that it hasn't created yet (funny how that won't work!) or has a typo which is making it ask to use the name of something that will never exist, or something has caused the widget to be deleted earlier than expected. Without seeing the code it's hard to be sure which. A typo is fairly possible, as is failing to construct a compound widget name correctly (which is also a kind of typo I guess) but putting the manipulation code before the creation code is definitely a possibility. An early delete is less likely in general but can't be discounted.
As the code is apparently well over a thousand lines long, I don't think it'll be easy to find volunteers to look through it.
I took over a TYPO3 site...
I would like to edit css file, in the inspector it shows me that the file is located: /typo3temp/vhs-assets-portal-css.css?1481533219
The problem is that .css?1481533219 is every time different (dynamicaly generated).
I edit already vhs-assets-portal-css but it doesnt apply changes live...
I would appreciate if somebody can help me, and tell me how this is generated and how to change this css file.
Thanks in advance!
Denis
The number after the question mark looks like a timestamp which might be used to do a fresh fetching from the server. This could be done to avoid a caching in the browser. This can be helpful if the file is generated on the fly and could contain changed content for every access. Especially if you a logged in in the BE.
For FE you should avoid such constructs as they increase traffic.
The name of the file lead to the assumption there is a call of the assets-style-viewhelper of ext:vhs. Have a look in your templates to identify the call and check whether it needs avoiding cache or whether the CSS-include might be better configured in TS.
I've been banging my head over the last day or so over a VERY WIERD issue I'm encountering with my Magento 1.9 site. All was working fine until I decided to add another language to the store (while disabling one of the languages already present). What I did was follow the same process I used to set up the language i.e. go to store view, and simply "disable" the language I did not want in the language selector drop down.
However, immediately after I did this, the theme I'm using stopped loading correctly. And no matter what I do (renable etc), it simply won't load any more. This is ALL I did BTW - I did NOT modify any other settings, code etc. . .
Is there something I'm missing here? Any input would be greatly appreciated!!
Did you tried to clean the cache? Any external cache?
Please check the other scopes. Perhaps you changed it.
I've been working out with this quite a long time and I can't find a way how to make it work.
I'm creating a simple theme option with my theme but putting all the options to a custom database table.
I want to know how $wpdb->insert() inserts all options like add_option().
This is my code - http://pastebin.com/5xHBs6r2
If you look at line 209 *function stheme_initialize_theme_options()* you'll see what I mean. I also created a function (*function stheme_default_options()*) that holds the default options and return it with apply_filters().
I hope someone can help me with this as I'm really struggling with it for a week now.
Thank you!
Best regards.
Consider using the Options API. It's a lot simpler than writing your own queries, and it's built in already.
http://codex.wordpress.org/Options_API
Setting, resetting and retrieving options you store can be done with 3 or 4 commands altogether, so it's a pretty nifty system. For instance, this:
add_option('my_option', 'foo');
Will instantiate an option in the DB, this will update it:
update_option('my_option', 'foo2');
and finally, this will retrieve it:
$s = get_option('my_option');
If you do use the Options APi, it's a good idea to stick to a naming convention, have your own prefix for your options. Too easy to cross over to other plugins etc if you use anything too obvious.
This is a classic XY Problem.
Don't create a table to do something that WordPress already does. You're even putting yourself into a trap, as you won't be able to query your data with WP default tools and will have to re-invent the wheel to achieve it.
What you're looking for is register_activation_hook, register_deactivation_hook and register_uninstall_hook.
Aside the uninstall hook, we can use the file uninstall.php with our plugins to clean up our stuff after the plugin is deleted. See this related posts at WordPress Answers.
PS: in your code, this is totally uncalled for:
add_action( 'init', 'st_register_table', 1 );
You address custom tables simply with $wpdb->prefix.'your_table'.
We have a website that uses #include file command to roll info into some web pages. The authors can access the text files to update things like the occasional class or contact information for the department.
My question is this, I don't see anyone using this method and wonder if it is a good idea to keep using it. If not, what method should I transition to instead?
I don't think there is anything wrong with it, and I've done some similar things with PHP. If the people that make the changes are comfortable with how they do it and they can do what they need to, I think you should stick with it. There could be some retraining involved and/or a fair amount of work involved for changing the system.
If you are using ASP.NET then you could bundle that code into a nice little UserControl that will display all of the important information.
Other platforms should allow you to bundle the logic into a class object, and display it using that.
It really depends on the platform that you are using to deploy the application in. The include file could be your best solution if you are deploying in a more limited platform.