I am working on 5.6.3.4. Just curious to learn why the single pages do not automatically get the active theme applied to them. It looks like I have to manually map the single pages to a theme inside the /config/site_theme_paths.php file or am I missing something? So everytime I create a new site I have to do the mapping for all single pages in /config/site_theme_paths.php. Not sure how it's done in 5.7 but that's a bit of a pain.
The only Single Pages you have to map with the /config/site_theme_paths.php are the System single pages (Login/Register/etc) the rest will use the view.php in your theme as the wrapper automatically. This is the same with 5.7 I believe.
Related
I've a weird issue in my Drupal 9 website where a couple of regions (subfeatures and footer) get rendered differently in different pages with no consistent behavior.
They are loaded via the theme's default page.html.twig and should render inside the page js-layout wrapper as in below screenshot
But in some pages, it gets rendered outside the wrapper like in the below screenshot
This is simple website with no overrides on the theme level for the regions so this is quite strange
Without knowing the theme, it is difficult to give an answer. (Which theme is used, which templates (which Twig file provides the theme) and so on...
But let me try to give you a starting point:
Check all twig files of your theme
If there is a multiple for page, like: page.html.twig & page--article.html.twig. Then check the HTML structure for it
Check the region's conditions
In the page-twig templates, check if the HTML closing tags depend on the region conditions. Is there a condition that the div sometimes closes earlier?
I hope this will help you.
On the catalog/category page I would like images change when hover. Like clubmonaco.com I know how to do it on html/css but no idea on magento. Any help?
You could modify files in this directory:
app/design/frontend/base/default/template/catalog/product
for example (list/ and list.phtml)
or your template for example:
app/design/frontend/default/yourtemplate/template/directory with product files
CSS files you can find in:
skin/frontend/
You should also think, where the second image is stored. You can use "CSS-Sprites" for this case - a single image file, that contains both photos. The disadvantage is, that you have to customize every page, where magento shows product images.
Alternatively you have to define exact orders. First image is the front view, second image is always the back view.
The programming part is not really difficult. Look at
app/design/frontend/base/default/template/catalog/product/list.phtml
for the Catalog view. Path can vary, if you have a custom template. In the Magento backend there is a feature to show up the real path (system->configuration->development tools).
You can write your Javascript directly into the list.phtml. Magento also writes JS-code directly in the .phtml files. Of course it's not very pretty, but Magento is so complex; if other people work with the shop system, it will be easier to find.
Keep in mind, that the list.phtml contains two layouts: Grid and List View. Just if you do a change and wonder, why you can't see a change in the frontend ;-)
I'm pretty sure I've read somewhere that you can actually move the main plugin *.php file to somewhere else (I assume under your theme directory) to have it safe in case you made changes to it and your plugin updates. I tried Google but I can't find anything. Google page with good results will suffice.
I've just experienced a situation where my 2 plugins which had its layout changed and accommodated my needs and I want to make sure it doesn't happen again. Apart from having the main file in another location, is there a way to move along any CSS and JS files as well?
In Concrete5 CMS there is a nice way of doing this, by creating a new folder inside a block of an addon (may be regarded as a WP plugin), inside of which you can create copies of main file, any CSS and JS files and then you can simply edit them and choose that template for a page location you are using that block in.
I assume there is no such thing in Wordpress but how close can I get?
UPDATE: I found where I applied that advice on creating a new instance of the file then moving it to the theme directory.
The plugin in question was HL-Twitter. These are the plugin files:
admin.php
archive.php
functions.php
hl_twitter.php
hl_twitter_archive.php
hl_twitter_widget.php
import.php
widget.php
Now, this is the top contents (commented out) of the hl_twitter_widget.php:
Widget Theme for HL Twitter
To change this theme, copy hl_twitter_widget.php
to your current theme folder, do not edit this
file directly.
Available Properties:
$before_widget
$after_widget
$before_title
$after_title
$widget_title
$show_avatars
$show_powered_by
$num_tweets: how many tweets to show
$tweets: array of $tweet
$tweet: object representing a tweet
$tweet->twitter_tweet_id
$tweet->tweet
$tweet->lat
$tweet->lon
$tweet->created
$tweet->reply_tweet_id
$tweet->reply_screen_name
$tweet->source
$tweet->screen_name
$tweet->name
$tweet->avatar
$user: represents the Twitter user (ONLY SET IF SHOWING A SINGLE USERS TWEETS!)
$user->twitter_user_id
$user->screen_name
$user->name
$user->num_friends
$user->num_followers
$user->num_tweets
$user->registered
$user->url
$user->description
$user->location
$user->avatar
So I was wrong about copying the main file (in this case hl_twitter.php), but still - this enabled me to edit the file outside the plugin directory and the system somehow checks for its existence and picks it up if exists.
If this behavior something that is natively supported by Wordpress or it has been integrated in the plugin itself?
With themes, Wordpress has a concept of "child themes" which allows exactly that: to keep changes separate from main theme, in case it changes.
I haven't yet found a way to do this with plugins.
I'm using a few tactics myself:
I bump plugin version to a very high number like 99.9. This way Wordpress won't ever update the plugin.
Store my plugins in version control (i use git, but it doesnt matter), this allows you to update the plugin, run the 'diff' tool and see what changes happend. If you don't like you just revert like it would be a bad code you've written. But this approach requires a bit of skill.
Are you talking about running parts of a modified 3rd party plugin, and an updated version, at the same time?
That's not going to be possible. There is no magical method of "preserve my changes and transfer them into the new version automatically". The way to go here is doing a diff between the edited version and the update, and integrating the changes in the actual source files.
The bottom line is, if you manually edit a third party plugin, you're in for manual review (and possibly rework) once an update takes place. That's why it's usually not a good idea to extensively modify third party plugins.
Well in fact, yes! There is some kind of way.
You have to remove the to be modificated plugin's original actions/filters and then add your altereted actions/filters.
If the desired plugin is even coded in OOP you can just inherit the whole class and rewrite the wanted functions (oh sorry: "methods". we're talking about OOP ;) ). Instantiate your inherited class and rest as above.
Maybe there are better ways! I already search for a method so that the original class won't even get loaded but our altered one instead but I'm no John Carmack.
I'm trying to slightly modify the default WordPress tag cloud widget. I don't want to create my own widget because I literally want to adjust one small thing. I've looked through my WordPress installation but can't find the PHP file that contains the basic widgets.
Even though I assume that they are defined in each theme, I still looked in the core directories but came up empty handed.
So if any of you happen to have already figured this out, please make my life easier and let me know where I can find the default widgets...most importantly the tag cloud widget.
Thanks
Those are located in the default widget class:
/wp-includes/default-widgets.php
For more detail:
http://phpdoc.wordpress.org/trunk/WordPress/Widgets/WP_Widget_Tag_Cloud.html
The widget invokes a function deeper though that generates the actual output. You'll want to take a look at the wp_tag_cloud and wp_generate_tag_cloud functions in:
/wp-includes/category-template.php
do take into account however that you'll lose your change when you upgrade wordpress (which is why I eventually did create my own shabby category-cloud widget instead of changing the default tag-cloud code).
The tag cloud widget is defined near the bottom of the default-widgets.php file in the wp-includes folder.
I know that I need to add the tracking code snippet at the bottom of all my pages, but is there a central location to do this?
Or do I need to add this tracking code to all of my templates?
I guess that I could wrap the snippet in a user control, or external .js file, and reference it on each page, but is there a global footer somewhere? The site I'm working on has about 30-40 layouts, and adding it to each one would be a pain!
Thanks in advance!
Actually, the role of a Sitecore layout is exactly this; to act as a global file that all individual page templates "derive" from.
Normally you'd stick the analytics code into the master layout, and use Sitecore sublayout/placeholder techniques to construct the various page templates you need. You would not normally need more than perhaps one or two layouts for any device you are serving content to. And I guess for most sites, the only device in use is regular web content delivery.
That being said, what you could do, is have all the layouts inherit their codebase from a common base class (inheriting from Page), and inject the google code centrally from here. Would still require you to go through all layout files however.
I have not tried the module, I think that is codebehind version. I have made this in XSLT, its pretty fast and easy to make. I have footer.xslt where I put the code that simply checks if page you are standing on uses template that I want to index and does not belong to page names that I want to exclude. Then I have an item with a custom template for Google Analytics with following memo fields.
IncludeTemplates -field contains list of templates that I want to include for analytics :
ExcludeItemsNames -field for excluding pages by item name
contains($includeTemplates, concat('|',./#template,'|')) and not(contains($excludeItemNames, concat('|',./#template,'|')))
Remember #key and #template is always in small letters
If you run many domains don't forget to add pageTracker._setDomainName("www.example.com"); in analytics script so you can separate sub-domains etc. if they use same footer.xslt
Normally we consider the actual Google code as content. Within Sitecore we normally have a settings folder, something like /sitecore/content/settings. This exists outside the root of the site. Beneath this have a settings item with a plain multi-line text field, I think the field type is memo or something similar.
Afterwards create an XSLT that renders out the content of this settings item. Something like (assuming the field is called value in the setting item):
<xsl:value-of select="sc:fld('Value','/sitecore/content/settings/footerJavaScript')" />
You may or may not need to set the disable-output-escaping attribute.
Then on the aspx page that your pages use as the template add a control that looks at the xslt rendering:
<sc:XslFile runat="server" Path="/xsl/footerJavaScript" />
The reason that we normally keep the javascript as content is this allows the client to change the analytics code without having to contact us.