Renaming functions and variables in an original theme - themes

I want to create a theme, using a default WordPress theme as the initial point.
According to WordPress Codex, the recommended way to do that is to create a child theme.
Unfortunately, that approach may noticeably affect the performance of a site, because both themes have to be called before the site is actually displayed. WordPress tends to be fairly slow on quite a number of popular hosts, so slowing it down even further is not something I would want to do.
At the same time, coding a theme from scratch seems to be inefficient when an open source theme is close enough to the desired result to only require certain minor recoding.
Question: if I rename the theme in the main CSS file, there's still a lot of function callbacks and variables addressing the name of the old theme (for example, 'twentyeleven'). There has to be some central location where these are called from. What things do I need to rename, in addition to the theme name at the top of CSS file, to fully rename the entire theme an prevent it from being updated, should the original theme be updated by WordPress development theme?

All functions and callbacks of a theme are only being used if the theme is activated. So if you copy the 'twentyeleven' theme into a new folder & activate it, only those functions are loaded even if they have the same name(s) as the original theme. To answer your question (going with the 'twentyeleven' theme):
Copy the 'twentyeleven' theme folder and give it a unique name
Edit the file style.css in your freshly copied theme folder. Change the Theme Name:, Theme URI:, Theme Author:, Description: & Version: values to match your desired output.
Go to Appearance->Themes and activate your new theme
You have now a 'twentyeleven' clone, but completely independent of the original files. Any updates available for the 'twentyeleven' theme will not affect your theme (there will be no updates listed for your theme).
HTH

you may be interested in html5blank, a boilerplate wordpress theme

Related

Hugo theme submodule marked as dirty, doesn't update

I'm using the Hugo Whiteplain theme for a personal site hosted through Netlify. I am following tutorial. When I push/publish on GitHub Desktop, I am told that my git submodule is dirty. As a result, I cannot change the theme's background color.
[submodule "themes/whiteplain"]
path = themes/whiteplain
url = https://github.com/taikii/whiteplain.git
What do I do to regain control of my theme? Can I change the color without dependence on this dirty submodule?
There are many ways to customize a Hugo theme. For instance, you can:
edit the theme directly and let it drift from the original project,
create a fork and use it as the theme to be able to pull updates
from the original theme while developing your own version,
edit the theme inside the website itself.
This last option means that you do not touch at the theme itself, but instead make a copy of any file you want to edit inside the tree of your website, following the same path structure, and edit that file.
For any element of any of the customization files (layout, css, scss, etc.) that exists both under the tree of your website and under the tree of the theme, Hugo will prioritize the element in the file under the tree of the website.
For any element not present in the tree of your site, Hugo will use what is in the theme tree instead. This means that you do not have to copy the entire theme or even entire files in your site, but only the elements that you want to customize.
If you choose this method and if you set your theme as a submodule following the Git submodule manual, you will never get into a dirty submodule situation.
Example
Let's say you want to edit the background color of your theme and that the variable is defined in a scss file under:
your_site
+ themes
+ theme_name
+ assets
+ scss
_content.scss
You need to keep the tree architecture and create a file under:
your_site
+ assets
+ scss
_content.scss
You can create a file from scratch, but an easier option is to copy the file from the theme and paste it there. In that file, you can customize the background color (or any other setting) however you like.
Note
I have found this way of customizing a theme (which is actually the way advised in the Hugo documentation) to be the simplest.
One situation where this method is not optimal is if you plan to use the same customized version of a theme for several websites. In that case, creating a fork of the original theme makes more sense as you can add your customized theme (your fork) as a submodule of all those websites and your customization is thus portable.

Hugo: adding more pages to single-page themes

Hugo is a general purpose website framework and a static site generator. However, most of the themes are single page themes.
Is it possible to add more pages to these single-page themes in Hugo?
I am specifically interested in the Dimension theme.
Thank you very much for your help.
This depends on how the theme is constructed. In Dimension's case, the answer is no - you can add new markdown files to your content folder, but they will only be rendered on the index page, not as their own individual pages. If you want to generate multiple pages, you will have to either edit the theme or choose a new theme that supports multiple pages.
To edit the theme, see the docs on customising a theme and creating a theme. You will also need to know Hugo templates, so the go template primer is an essential read. Editing themes can be a little tricky, but if you have worked with other templating languages then it is not too much different.
In your case, you will want to edit layouts/_default/single.html to create a single-page view for all of your markdown files. You will also need to edit layouts/index.html to link to them from the index page, otherwise no-one will find them.
Hugo is not just a general purpose website framework/generator. I have been using it for article publishing, news website and to generate a blog! Most of the themes are single pages because people created themes in the way they love. Although still in development, you can check my website Desktop Luxury that is fully static and built with hugo. It's super fast, supports AMP and users just love it. They can't tell the difference between Wordpress sites and Desktopluxury.com in terms of look. Note: The difference is clearly visible in terms of load time, speed and customization ability!
Although it varies by theme, you can easily create a .md (file that contains content - similar to .html*) file out of your blog folder. For example, you want to create an About page. In the root folder that contains your hugo files, create a directory root/content/blog. Add permalinks to your config file that tells the theme to categorize files present in /root/content/blog folder as the blog files. Create the pages such as an about.md & contact.md in root/content folder. They won't show in the blog list, however, they'll be rendered and accessed by siteurl.xyz/about or siteurl.xyz/contact.
*I said .md file similar to .html file as the OP seems new to webdevelopment.
EDIT:
Final homepage after adding few posts
I just downloaded the theme mentioned in the question, added few .md files by opening CMD in the root directory of Hugo website folder and running command ~~ $ hugo new professional.md ~~
Created various pages and added content in them just like we write articles. I achieved the result you wanted with no issue at all. It was super easy!

Magento Extension/Theme Packaging

just a quick developer question in regards to Magento Extension/Theme Packaging, more specifically, when packaging, would I place the template files, layout files, skin folders etc in the base folder (see path below)(and not overriding any core files either)
app/design/frontend/base/default/template
app/design/frontend/base/default/layout
skin/frontend/base/default/css
and so on? I see this would be most suitable as alot of platform users would have custom themes with maybe custom namespaces for the theme folders. As users would have to stuff around to rename/move files/folders to work with their platform if packaged the default way I have seen in the past (ie in the default/default folder paths).
cheers for any feedback
This is the only way to package extension to use base/default or default/default location for template, layout and skin folders. Because if custom theme is used, then also this will work due to Magento's fallback mechanism. And if user want to add those files in custom theme location, then he/she should manually copy or move files in theme's respective location as you have said. And it is obvious that we can not predict custom theme path while packaging extension.

Uploading Aheadworks blog extension to my custom Magento theme

I'm fairly new to Magento and am having trouble uploading the Aheadworks blog extension to the correct directories. I am using a custom theme for my site, let's call it "themex". The directions state "Navigate inside step_1 directory. If you use a different from default theme - be sure to rename step_1/app/design/frontend/default/default and step_1/skin/frontend/default/default folders to your store's values."
I've located the 'step_1' directory but I'm not quite understanding the latter part of the directions. Am I renaming the 'step_1' directory to "themex" and uploading it to the root directory? Please be as descriptive as possible in your response.
Their instructions are badly phrased, but I'm pretty sure it means that you need to upload the files to app/design/frontend/default/themex
Magento theme files appear in the app/design/frontend/ folder.
The "base" folder here contains the core layout files, and the "default" folder contains the file overrides for other themes. As such, your theme's layout files will appear under app/design/frontend/default/themex (possibly app/design/frontend/themex/default depending on how the theme works)
Magento will first look for design files here first, and then look under app/design/frontend/base if the override does not exist.
Make sure you back-up any files, and if their files over-write any of your theme files then run a comparison on them to make sure they are not over-writing any of your theme's functionality.

Does magento touch theme folders during updates

I am working on a Magento project and it is due an update; so I am wondering which folders will it replace/affect during an update. I am used to working with wordpress which leaves the entire 'wp-content' folder ( all the user data ) untouched during an update - I presume magento does something similar and doesnt overwrite custom theme files, media uploads (and hopefully not products and user data anyway) but then I read the following from this page which confuses me
For several of the first Magento themes I built, I copied the layout files from the default or blank theme into the custom theme layout folder. I would then modify the layout files directly, editing or commenting out content in files like: catalog.xml, page.xml, checkout.xml, etc… I never liked editing these files directly, as I knew that when it came time to upgrade to a newer version of Magento that had upgraded the layout files, I’d have to merge the changes into the new layout files.
I think I may just have a mistunderstanding specifically about layout files but all the same could someone clarify for me which locations (if any) that I might expect to loose data from during an update ( so that hopefully I can avoid using these locations )
You won't loose any data if you have made your edits in custom theme package/folder and not in core code (but in tyour own extensions and code/local code-pool). However as you mentioned yourself it would be wise to merge your theme to be based on new layout files and same goes for template files as well
you can use a diff tool for that that can compare entire folder structures (winmerge, things and so on) and compare your theme and base theme folders
lets clarify things
whatever you change in code do it by making extensions in app/code/local/ or app/code/community
by merging your theme based on = if new version of magento is available and your theme is based on old version layout files and templates eq you have copied layouts and templates and modified them then it is wise to compare all changed files against new ones and apply your changes on top of new layout and template files

Resources