I want to modify the code for the Order/Sales table in the admin interface and the PDF generation code without alterting the files in the core directory. How do I do this? I understand that I have to create a new module that uses the same paths as the files I want to overwrite, but I'm not sure what else I have to do...are there some special steps to go through for the config.xml of the module??
If you want to do it in a separate module, you should put your new model (block, helper or whatever you need to override - I'll be using the model example, its the same for the others - only the controllers are quite different) in the 'Model' directory (for instance: code/local/MyNamespace/MyModule/Model/Sales/Order.php). In your modules config.xml you should add:
<global>
(...)
<models>
(...)
<sales>
<rewrite>
<order>MyNamespace_MyModule_Model_Sales_Order</order>
</rewrite>
</sales>
</models>
(...)
</global>
Of course your own Sales_Order model should inherit from the core one. This is the cleanest way to override Magento core functionality (maybe besides events, but they can't do everything).
Create matching directories and files that you want modified in the local folder for the module. That should be all that is needed.
As mcmil correctly pointed out, create a module in your own namespace and extend from the core class. By doing this you are writing less code and creating less bloat. It also improves your upgrade path in the future.
If you simply copy the whole file from app/code/core to app/code/local and then the core file/class gets changed in the next Magento update you might miss out on those changes. If you are extending from the core class with your module then your new class will inherit those changes when you update Magento.
Related
Background
I'm trying to remove resize-observer-polyfill from an nx workspace that I'm working on because it's natively supported in the browsers that we are targeting. Once I removed the polyfill, I needed to add #types/resize-observer-browser because the workspace currently uses typescript#4.0.5 and my understanding is that TypeScript does not have a "native" type for ResizeObserver until v4.2 which I'd love to update to, but can't atm.
Problem
In order to make TypeScript happy, it seems like I have to go in and manually add "resize-observer-browser" to individual tsconfig compilerOptions.types entries. This didn't seem that bad to me at first. I just updated the tsconfig.lib.json file of the libraries that happened to utilize ResizeObserver. However, I soon realized I needed to also add it to the tsconfig.spec.json of the libraries so that the unit tests could run, and then I also needed to add it to the tsconfig.app.json of any applications that happened to import those libraries.
Question
Is there an easier way in an nx workspace to handle this sort of problem?
I think that I could remove the default types overrides in each of the tsconfig files, since that would let TypeScript just utilize everything that exists under node_modules/#types when compiling. I didn't want to take that path since I assume there is a good reason for the default nx library/app generators to add the types override (I assume it's to force you to be explicit and not accidentally get away with accidental imports of test code from business logic).
The docs seem to recommend against this for #types packages, but /// <reference types="..." /> (e.g. /// <reference types="resize-observer-browser" />) can be also be used to include types, and might be easier to manage if the type is only used in a few places.
Docs: https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-types-
I have some data (logins) I want to be ignored from git in my custom TYPO3 extension code.
As AdditionalConfiguration.php is already ignored in my case, it seems a good place to store such data.
It normally contains Data like
$GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['dbname']
Now would it make sense to make something like custom globals? Does that exist?
$GLOBALS['CUSTOM_CONF_VARS']['MYEXT']['username']
Should and can I do that or not?
I think you can use your own globals. But I would consider using your own globals as bad programming style.
If you have installation specific data the right way to store the data depends on the kind of data and where you need it:
everything for the Frondend should be stored in typoscript. This can be in a file from a site-extension or in the database (template record)
for BE you could use Page- or User-TSconfig. here you also can use a file from a site-extension or database records (pages/be_user)
if you have FE and BE or anything alse (e.g. scheduler jobs) you can use extension specific global data, you can set in the extension manager. -> docs.
Instead of saving configuration in $GLOBALS try use typoscript. Will be much easier to keep and maintain it.
In SugarCRM, you can create your custom modules (e.g. MyModule) and they are kept in /modules just like stock objects, with any default metadata, views, language files, etc. For a custom module MyModule, you might have something like:
/modules/MyModule/MyModule.class.php
/modules/MyModule/MyModule.php
/modules/MyModule/language/
/modules/MyModule/metadata
And so on, so that everything is nicely defined and all the modules are kept together. The module becomes registered with the system by a file such as /custom/Extension/application/Include/MyModule.php with contents something like:
<?php
$beanList['MyModule'] = 'MyModule';
$beanFiles['MyModule'] = 'modules/MyModule/MyModule.php';
$moduleList[] = 'MyModule';
Obviously, the $beanFiles array references where we can find the base module's class, usually an extension of the SugarBean object. Recently I was advised that we can adjust that file's location for the sake of customization, and it makes sense to a degree. Setting it like $beanFiles['MyModule'] = 'custom/modules/MyModule/MyModule.php'; would allow us to access the base class via Module Loader even if the security scan tool prevents core file changes, and this would also allow us to not exactly extend, but replace stock modules like Accounts or Calls, without modifying core files and having system upgrades to wipe out the changes.
So here's my question: what is the best practice here? I've been working with SugarCRM pretty intensely for several years and this is the first time I've ever been tempted to modify the $beanFiles array. My concern is that I'm deviating from best practice here, and also that somehow both files modules/MyModule/MyModule.php and custom/modules/MyModule/MyModule.php could be loaded which would cause a class name conflict in PHP (i.e. because both classes are named MyModule...). Obviously, any references to the class would need to be updated (e.g. an entryPoint that works with this module), but am I missing any potential ramifications?
Technically it should be fine, but I can see how it could be possible that both the core version and your version could conflict if both are referenced. It all depends on the scenario, but I prefer to extend the core bean and find somewhere in the stack where I can have my custom version used in place of the core bean. I wrote up an example a couple of years ago here: https://www.sugaroutfitters.com/blog/safely-customizing-a-core-bean-in-sugarcrm
For most use-cases, there's a way to hijack Sugar to use your bean at a given point.
If you can't get around it you can always grep to see where the core module is explicitly being included to ensure that there won't be conflict down the road.
I can't find a good answer to this simple question:
Where can I add my i18n files in a GWT project ?
I see two solutions:
- create a module and add all i18n files for this module in this module
- create a complete different structure to put all i18n files (no matter what module) in the same directory (and so, easy to create a new language)
My feeling is that the second approach is better but in gwt samples, it's the first approach which is generally used.
And you, what do you do with yours i18n files ?
Thanks
1) Create a separate package in your module. Dump all message files there along with the property files.
2) As a best practice create a base message class and EXTEND other message interfaces from the base one. You can reference base message class in code and depending on which instance of message class you point too, your actual value will change.
Another approach, create a new i18n module and inherit that in your actual model.
1) Allows all messages to be in one place.
2) Easy to hand over to localization people for translation.
I usually put the i18n files (*.properties) in the same package as the Constants (or any other i18n related class) derived interface that's using them (less hassle with setup) - usually the package is named i18n.
I am trying to create Web Services from the Top-Down approach. I downloaded Eclipse and am using the WSDL gui editor in it to build my WSDL files.
I am splitting up my Services based on "modules". The Types I am adding to the WSDLs all need to reference common stuff, such as PersonEntity, AddressEntity, States enumeration (simple type), Countries enumeration (simple type), and AbstractEntity. Since those items are all common I created a seperate WSDL file (named Commons.wsdl) that contains the type information for those types.
I want to "import" that WSDL into my other WSDL files to use:
For example, I have an entity named RegistrationEntity which inherits from AbstractEntity and contains a PersonEntity as well as an AddressEntity. I'm not sure how to do this... I saw that the WSDL spec has "import" and "include" and am not sure which one to use. Also, how do I actually import (or include) the Commons.wsdl file so that I can use the Types defined within it?
Thanks!
Oh, and I'm not sure if I'm supposed to stick this stuff in a seperate WSDL but another type of file such as an xsd or something. I really wanna follow best practices so if that's the proper way to do it then I'd rather do that.
I found out that the problem I had was I was creating a WSDL file for my commons and using an inline scheme for that, rather than creating an XSD file to be imported by my other WSDLs.
So instead I just created an Commons.XSD as my "Common Schema".