There are many examples of how to override a core module in Magento, but how does one override a local module?
You don't override a module, you override (or, more properly, rewrite, see below) a class that belongs to a module, or belongs to the general lib folder.
Based on your wording, I assume by override you mean "taking a class from app/code/core/" and placing it in "app/code/local/"? If that's the case then you mostly can't. Code pools work because magento adds four paths to the PHP include path.
app/code/local
app/code/community
app/code/core
lib
Then, when the autoloader says
include('Mage/Module/Path/To/File.php');
if will first check the local folder, then the community folder, then the core folder, and finally the lib folder. The local folder always wins.
If your class is a Model, Helper, or Block, I'd suggest using the module based rewrite system. The same techniques you use to rewrite classes in the Core modules can be used to rewrite classes in local or community modules. The point of a module based system is that the code which runs the core system is inserted / behaves the same way as code other people might add to the system.
Related
When I use some package manager like Composer I want to use some 3rd-party module and to have an ability for example to change some views (templates) of this module, and simultaneously to have an ability to update this module trough composer.
How can I do this?
If not - may be it is question to think about to integrate to package managers some pattern to have an ability do this well ?
Pattern - I mean some rules with that programmers will be able to show some files that will be able to be edited by consumer and to do it, developer should do some api for it by some standartized method that will be written in rules, f.e. in some composer config of his module developer will write, what files should be duplicated to userpath. After install, these files will be copied and user will be able to change it, and composer will do it able modules to see these files in users folder. And after update this user folder will not rewrite these edited files... Something like that or maybe somehow more flexibly
How to modify views of packages installed by composer in Laravel:
https://laravel.com/docs/5.0/packages#views
Customized views should be placed in folder /resources/views/vendor/
with same names as original
This is the first place where views are searched by framework
I'm new to Xamarin framework, and as I created a new Android Application I noticed the MainActivity.cs class located in the root of the project. I'm also new to C# so I don't know if all files are supposed to be on the root, but if not, will there be any issue if I organise my classes in packages/folders?
There is no problem with organizing classes into folders. Namespaces are much more important than the physical location of the files, but it's good practice to have your namespaces reflect the folder hierarchy.
For example, if you create an Activies folder on the root and move MainActivity into that, the namespace in your MainActivity.cs file should be YourAppName.Activities.
When you add new files into an existing folder, this will be done for you, but moving existing files into a folder will require a manual refactor of the file's namespace.
Unlike Java in C# you are not required to place a class in any particular file, indeed you can place a class in multiple files (this happens when you use Xaml) or more than one class in one file.
That said I would recommend you place each class in a file named after it and that you, in general, make a folder for each namespace. However I have seen some mysterious crashes and "could not find class that actually where there" related to this, so you may have to skip that if you find weird issues with Xamarin Studio.
I have a composer project, call it MyVendor\Database. That project uses composer and autoloading. There are several files in that project that have:
require_once __DIR__."/../vendor/autoload.php";
in order to utilize autoloading.
It all works great, until I include MyVendor\Database in another project.
I have another project, call it MyVendor\CoolPackage that requires MyVendor\Database.
I run composer install on CoolPackage and it downloads MyVendor\Database into the vendor folder.
The problem from here though, is My files within vendor\MyVendor\Database fail because they call require_once __DIR__."/../vendor/autoload.php", but there is not vendor folder inside of \vendor\MyVendor\Database.
In your composer.json you define the autoloading scheme. For reasons you found out yourself now, it is not a good idea to call the Composer autoloading inside any of the files that are supposed to be autoloadable not only inside that application or module, but in any other application as well.
Basically, the files in any Composer project should be divided based on the definition of PSR-0 or 4 autoloading: They either ONLY do declaration of classes or functions WITHOUT any side effects (like executing code), or they execute code without defining classes or functions. Only the former files can be autoloaded (with the exception of functions, which would only be able to always be declared by loading the file containing them with a files autoload section), the latter should NOT be autoloaded.
And then it should become relatively easy: All the classes that can be autoloaded can also be used when this component is included in another application. Anything else that is not a class cannot directly be used.
So, I'm making a CMS at the mo, and using the modular extensions HMVC CI 2.0. It's lovely. I'm wondering the correct method for keeping my assets (js, css, img) related to a module within the module directory.
The problem being, how do I link to these assets? Let's say I'm using a template engine and passing the js files to load for a specific page:
$js[] = 'assets/js/my_js.js';
I suppose I'm asking this all wrong, but is there an easy way to link using the current module's directory?
Thanks in advance.
There's nothing currently built in to CI or HMVC for this.
I prefer not to reference files that are allowed direct access, like images/js/css, from within the application directory. Mainly because:
I don't want anyone to know what the guts of my app look like. By referencing files from directly within a module, you expose your application's directory structure.
I would never do this if I weren't using HMVC
You must now allow direct access to (certain) directories within the application via .htaccess. For security reasons, I prefer to simply disallow the entire thing.
I understand the desire to be as modular as possible, but to me it's not worth this hassle. I prefer to keep a separate directory in a public folder called "modules" (duplicating my application/modules structure), that has nothing but "assets" (css, js, images...).
I'd offer some code but I have no clue how you are adding js/css to your views - it's probably much different than the way I do it. It would be easy enough to write a function to detect the current module, controller, or method and change the asset folder automatically, but this may interfere with other shared assets. I'd suggest writing an entirely separate function for loading assets from modules.
Is there a recommended location to store static resources (images, css, js, etc) in a DotNetNuke 5.x installation?
There are /images and /js folders as well as a /Resources folder that contains resources. There appears to be some overlap as MicrosoftAjax.js is in multiple locations (but might be different versions?). I also could put resources in a /DesktopModule/ModuleX location.
Does anyone know if there is a difference in using any of these folders?
I kinda like the idea of all static resources being under a common folder (/Resources) so I could set caching rule headers, permissions, etc on them in one place.
Has anyone used a separate image server to serve DotNetNuke static content?
Pros and Cons of a separate image server (e.g. images.mydomain.com)?
If you own the entire DNN installation, then it can certainly make sense to consolidate all of your resources into one place (whether its the Resources folder used by DNN, or a different folder that DNN doesn't know about). If you're developing a module that will be installed onto a site that you don't totally own, then the considerate thing to do is to constrain your resources within the DesktopModules folder for your module.
Some things to consider with regards to DNN folders:
If you have content under a module's folder, uninstalling that module will give you the option to delete that content. This can help you keep things clean and organized, or it can make it can be dangerous if you have multiple module definitions sharing the same files... (Even more dangerous can be the uninstall SQL scripts; make sure you don't accidentally uninstall a module which has an uninstall script attached)
You can use the DNN file manager to upload/delete/rename files within the Portals directory, so it may make sense to put files there if site administrators should have control of them
Putting content outside of the module's folder will make it slightly more difficult to link to (especially if it's on a portal specific folder, i.e. you have to ask the PortalSettings object for the path every time)
It's uncommon to keep resources outside of the module's folder, and so may cause confusion if you bring an experienced DNN developer into the project
For skins and containers, you can use their own folders under the Portals directory. As bdukes said, this way site administrators can control them within DNN.
For modules, I have used the module's folder and module.css for defaults that can be overridden by skin or container css. This works because skin and container css are loaded after the module.css.