I am looking to create a module for a customer, but I have to override the product_variants.tpl from the prestashop classic theme.
I have two questions:
Is there any way to override it without edit the original file? Should I need to create a copy of the entire theme or is there a cleanest solution?
If I will override that file and my customer would like to change the classic theme with another one, I have to change the override again because the file will probably have another name and not 'product_variants.tpl', right? Is there a modular way to do this?
Thanks in advance!
There is no officially way to override the core template files of the theme from module. The best way is to create a child theme, and override only the files you need.
https://devdocs.prestashop.com/1.7/themes/reference/template-inheritance/parent-child-feature/
The answer to the second question is yes. And it works correctly, because each theme has its own structure, and it's possible that the modifications you've made to the old theme might cause the new theme to not work properly.
Related
This is a follow up question to this:
Adding custom style format to tinymce editor
#Mangirdas Skripka or other Impresspages people:
In the answer to the above question: Are you suggesting to make an own version (widget/plugin) of the tinymce plugin or can I just override tinymce's default.js in my own mytheme/override folder?
Putting edited versions of default.js and Event.php in my theme's override folder does not work, not with any of these locations:
test 1: mytheme/override/Ip/Internal/Core/assets/tinymce/default.js and mytheme/override/Ip/Internal/Core/Level.php
test 2: mytheme/override/assets/tinymce/default.js and mytheme/override/Level.php
Can the standard text-plugin (tinymce) be overriden or do I need to make a new plugin/widget?
Thanks for your help!
Override folder is just for view files. JavaScript or other PHP files can't be overriden in override folder.
And dues to JavaScript nature you don't need files to be overriden. JavaScript allows you to override anything at any time. You better go by duplicating one of the existing plugins and adding your own rules.
I recently started to create custom theme for ExtJS 5 by Sencha.
Following http://docs.sencha.com/extjs/5.0.0/core_concepts/theming.html I managed to create ThemeDemoApp, inherit ext-theme-neptune, change $base-color to green and refresh/rebuild ThemeDemoApp with my-custom-theme. All ok.
My problem is, ThemeDemoApp is quite poor for testing a custom theme. A panel, tab, button and a modal window. That's it?
After bit of googling I bumped into http://dev.sencha.com/ext/5.0.0/examples/themes/index.html. (Why isn't this mentioned in the guide?!) Heading says: View and test every Ext component against bundled Ext Themes, or your own custom themes.
My question is: How? How do I test my own custom theme against this example? Do I have to dig into the source (themes.js) and build such page/application myself?
The examples - including the Theme tester - is included in the ExtJS download.
You can modify the list of themes available by editing the shared/options-toolbar.js file.
To get it to find your theme, you'll either need to name it similar to the others (ext-theme-name), or modify themes.js accordingly.
Or you could just hack the theme.js file to hardcode your theme.
(Ext JS 4 used to create an example page for themes automatically - it doesn't seem to do that now, though)
According to advice at How do I include a JavaScript file in another JavaScript file? I decided to load both options-toolbar.js and themes.js (with just minor modification - commenting out Ext.onReady(...) function in themes.js) and I used functions getBasicPanel(), getCollapsedPanel(), etc. in my own application to create the same testing page (absolute-layout container that fits the page).
Anyhow, I guess Robert's answer is the correct one - there is no prearranged, ready-to-use functionality from Sencha :-(
Is it possible to use a custom view file in a module (eg. user) in order to keep the module (3rd party) intact?
Somehow extend the module, with a views folder that holds my custom views.
The path to the module theme views should be
/{{your_app_name}}/themes/{{theme_name}}/views/user/
Copy all of the module views from the folder
/{{your_app_name}}/protected/modules/user/views
to the mentioned above folder and that will do the job. After that you could customize the views as you like.
Copy user module view files to <app>/themes/<current_theme>/views/user/. More general, customize module views using the folowing "formula": <app>/themes/<current_tehem>/views/<modules_name>/<controller_name>/<view_file_to_customize>.php
Use a theme. For a module named "user" and a view path of "profile/edit", create "/themes/flashy/user/views/profile/edit.php". You can also define a new layout in "/themes/flashy/layouts/column2.php". Then add to your configuration file in "protected/config":
return array(
// many settings...
'theme' => 'flashy',
For the module "user" you pointed out, unfortunately its controllers use absolute paths for their layouts (e.g. "//layouts/columns2") so AFAIK you can't define distinct layouts for the application and this module.
See also the official guide chapter on theming with Yii.
I disagree that in many help forums of the Internet, when someone asks abot theming a module, everyone suggests a path alias to the themes folder. I think this is wrong, because it implies modules to be splitted, and modules are supposed to be a black-box that can be used across projects. The advice given in such forums would only be valid if a theme is shared among several modules. If someone wants to "package" a theme inside a module, she can:
-add an init function to the controller of the module
-inside that init, use the class attribute layout and a path alias, like this, supose a module whose id is "Sample":
then you add, to SampleCOntroller.php:
public function init() {
//BELOW: it will use the layouts/main.php inside the module.
$this->layouts = "sample.views.layouts.main";
}
I have a task, remove all modifications directly to the buddypress plugin, I started by replacing bp-default, with a new fresh downloaded copy, and the site stopped working.
Clearly, the site was dependent on something in that dir
So my question is:
Is modifying the bp-default dir consider acceptable?
Its suggested, and is a good practice to not modify anything inside the bp-default theme. So as of your question, 'no its not considered acceptable'.
That is because a future update of buddypress will replace everything you've changed. So its better to create your own child theme and do all the editing there.
I am working on an Eclipse RCP-based application, and we have decided that we do not want any of the menu items to display icons next to the text. The problem we are seeing is that the standard actions like Undo, Redo, Cut, Copy, Paste, and so on all display the default icons for the corresponding actions.
Is there any way to tell the action management infrastructure to ignore the icons? My brute force solution to this was to rebuild the SWT so that MenuItem.setImage() was a no-op, and then include our own copy of the SWT in the final product, but it seems like there should be a lighter-weight solution.
This turned out to be easier than I had hoped.
Create a subclass of org.eclipse.ui.application.ActionBarAdvisor. Override the method register like this:
protected void register(IAction action) {
super.register(action);
action.setImageDescriptor(null);
}
Then, create a subclass of org.eclipse.ui.application.WorkbenchWindowAdvisor that overrides createActionBarAdvisor:
public ActionBarAdvisor createActionBarAdvisor(IActionBarConfigurer configurer) {
return new MyActionBarAdvisor(configurer);
}
That's it. All actions will no longer have icons.
I believe you want to further examine going into the manifest and looking into
org.eclipse.ui.views and seeing if there is anything in there for removing icons
What is the reason for not including icons?
A lot of effort went into creating a standard interface, what would be the benefit of deviating from the standard? Do you think their omission increases usability?
Having said all that you could try contributing a fragment with some AspectJ around advice to intercept calls to setImage() and veto them.
You can do this by going to the extension tab in plugin.xml.add the extension org.eclipse.ui.menu (if not present).Right click create a new menu contribution.again right click and create a new menu.here u have the option to change the images with the ones saved in your icon folder in your class path