Home » Development » WordPress » Page 7
Sometimes you might like to store all language files in your own central location, so that translators have one easy place to access all language files.
Put the above into the functions.php and add textdomain handling for those you want to centralize.
Most current plugins should include the option to store language files to the global WordPress language folder, but that is sometimes just not enough :) Its all about options ;)
WPLMS is a Learning Management System for WordPress. Translation files in WPLMS are located in
These language files will be overwritten with new files on every update, destroying any custom translation changes.
Move your theme into a child theme and translate your theme there (/wp-content/themes/your-child-theme/languages/).
Make sure that language files are loaded from your child theme. Add the following action to your functions.php and use “vibe” as the domain, not the actual theme name.
Use the global language folder for the WPLMS plugin translations. The WPLMS plugin loader checks, if a global language file actually exists :)
I suggest using Poedit, as it allows you to do the translation on the Desktop. It also offers options to update your file with an updated WPLMS language file, allowing you to add new translation strings if needed :)
A. Create the structure for the update and download new PO files from WPLMS
B. The target structure / your current language files
C. Open your current .PO file from target structure
D. Update with new and matching .PO file from A. (Catalog -> Update from POT file)
This will check for new or obsolete strings and update your language file.
E. New strings added
F. Obsolete strings removed
G. Save and upload updated .PO + .MO files from target structure to server.
Again, make sure to use the global language folder and the child theme languages folder !
Panic time after updates is over :)
TWIG allows you to use regular expressions within its templates, this makes it possible to easily check if a post is sticky in Timber for WordPress.
Comparisons in TWIG
This is the template that is called within the loop on the index.twig to show each post.
The post.class holds the full set of classes assigned to a post, which includes the class “sticky”. We do the match magic and you can use that to style your sticky posts differently ;)
“Timber helps you create fully-customized WordPress themes faster with more sustainable code. With Timber, you write your HTML using the Twig Template Engine separate from your PHP files.
This cleans-up your theme code so, for example, your php file can focus on being the data/logic, while your twig file can focus 100% on the HTML and display.”
Twig is a modern template engine for PHP
When building plugins or addons, sometimes we need to save custom files within WordPress.
These can be custom JavaScript or CSS files that a user edited and are loaded to override core functionality.
In most cases inline styles and scripts are an option, but not always the most elegant way. Everyone has to decide that for themselves. (wp_add_inline_style) Not talking about performance between inline and external files here :)
Another option is the wp_head action:
Many ask where can or should I save files created within a plugin.
When dealing with file creation and uploads, security is always important. That relates to any other platform doing similar operations. A folder created within a plugin directory is not less or more secure than a folder created in the upload directory.
Its important to have the correct file and folder permissions set:
There is a detailed article about permissions over at WordPress as well.
When it comes to creating files in PHP the term cross-site-scripting often comes up. When the system creates a file it is owned by the webserver and on a shared hosting account those files could be altered by another user on the same webserver. This could allow them to inject malicious code and compromise your sever.
That is why the WP_Filesystem was created, to make things more secure and make sure that the owner of files is correct.
WordPress provides a nice clean interface to create folders and save files to the upload folder. Here a simple example from one of my current projects.
Prepare the filesystem
Get upload dir information and prepare directory to save to
Check if file exists, create folder, delete similar and save. In my case I am adding a custom key and the page id to the file.
If the direct way is not possible, you can also use or force the FTP approach (request_filesystem_credentials).
This will check for the ftp credentials and request them with a form if needed.
This is just a very rough outline of how to do it, but should get you started.
The custom maintenance mode message in WordPress, during upgrades and installs, is far from beautiful :) Time to change that!
You can do your own page by adding a pure PHP maintenance.php into your /wp-content folder.
Now go and build a nice page !
Just remember that during maintenance no WordPress functionality is available!
The files author-course.php and author.php can not be overwritten in a WPLMS child theme directly. The only way is to override the filter in the child theme functions.php:
“WPLMS is a Learning Management System for WordPress. It is an e-learning WordPress theme for course management, instructor and student management using which you can create and sell your courses online. “
When mapping shortcodes using vc_map, you can assign icons to your new Visual Composer element.
If you created a container element, that wraps around other elements, the child element icon will currently be overwritten with the parent icon. A fix is apparently on its way :)
Currently the only way is to skip the icon option completely and use pure CSS for that.
You can enqueue a CSSs file for the admin through a vc_map option “admin_enqueue_css“.
The CSS targets the icon of the displayed element in the editor and the icon when adding new elements to the layout.
This video should give you a good idea what the addon can actually do.
In my last article I gave you a rough overview of the features & requirements. Here some more details and additions:
The addon is mostly done. I am finalizing the main admin area this week and will do a final cleanup next week, for the first beta release.
Many people have asked me for a release date. I currently plan to have a fully working Beta in the next 2-3 weeks. Will offer the Addon to a small closed group of customers first, before I think about other release options. I think I will offer between 20-30 slots for the beta run. If you are interested let me know.
Regards Alexander
Update: Video Preview
I am still busy finalizing the Fullpage.js Addon for Visual Composer. Hope to have some more images or even a video next week :)
Some requirements for the Visual Composer Addon:
The Addon will ease Fullpage.js integration immensely, but for a more advanced integration some CSS / JavaScript knowledge will always be needed. Do checkout the main Fullpage.js documentation for more information.
