Lets take the fallowing example:
In my website i have two plugins: plugin1 and plugin2.
Both these plugins happen to use "Data Tables" so that means that the server hosting the Wordpress Website ends up with two copies of "DataTables" because each plugin has its own paths to enqueue the scripts and styles.
If i am the person developing both plugins how can I avoid copying "DataTables" twice on the server and make plugin1 and plugin2 independent from each other.
Conditionally include your code by placing inside a function_exists check:
if (!function_exists('DataTables')) {
// will only run if DataTables is not defined already
}
Related
I am using Lando for local WordPress development.
But because it relies on Docker the performance isn't great out of the box. To solve that problem the Lando devs say we can exclude files and folders from Docker to speed things up.
So far I have excluded three folders in my .lando.yml file, like so:
name: my-blog
recipe: wordpress
config:
webroot: .
excludes:
- wp-admin
- wp-content
- wp-includes
This has made the WordPress admin and front end considerablly faster on my local machine.
But then I tried to squeeze out every last bit of performance by excluding the entire root wordpress/ directory, like so:
name: my-blog
recipe: wordpress
config:
webroot: .
excludes:
- .
When doing this I ran into issues where changes on the site (such as edits to pages etc) were not being saved.
With that in mind I have three closley related questions:
Why I can exclude those three folders mentioned above but not the root directory?
What are the potential draw backs of excluding even those three folders I mentioned above?
What are the exact WordPress files and folders that are considered safe for exlcuding this way?
Why I can exclude those three folders mentioned above but not the root directory?
It depends on what files change. Excluding a folder means only the copy inside of the container is used and you'll have to rebuild to pick up any new changes.
Think of it like this, without exclude you're creating something close to a symlink. This is where the slowness comes from, every time a file is touched in the container the filesystem has to reach outside of the container and get the file from your local filesystem.
Adding an entry to exclude is basically making a copy of the file inside of the container that does not get updated.
What are the potential draw backs of excluding even those three folders I mentioned above?
Any changes you make on your local machine in excluded folders will not be reflected in the container like you're used to happening.
What are the exact WordPress files and folders that are considered safe for excluding this way?
This depends on what you're doing honestly and how you've installed WordPress. If you've installed it via a package manager, excluding those managed folders is typically very beneficial (ie, vendor/node_modules/etc). If you do this and make changes via your package manager, you'll have to rebuild the container or ssh into the container and rerun the package manager
But it really depends on what you're going to be changing. If you're working on a plugin or a theme then you'll need to ensure the plugin or theme folders is included, and so on.
For parts of the filesystem you aren't touching or aren't concerned with seeing, it is probably safe to exclude those. They will still work within the container, you just won't have easy access to inspect anything created/altered.
I'm updating Fishpig Wordpress-Integration to version 4.5.1.5 (with addons ACF, CPT, CS, Root, Multisite) in a new ansible-deployment. Now I get the follwoing error in the Magento-Backend :
Permissions The following file must be writable: /path/to/magento/wp/wp-includes/l10n.php
Why at all should a magento-module have write-permissions on a wordpress-core-file?
We prefer strongly to have separate concerns, so that the wp-core-files can't be compromised by anything from magento-side.
The questions are:
for which task in Fishpig (or it's addons) this write permission will be used?
could the _validateL10nPermissions() be overwritten for not checking this file without loosing an important functionality in Fishpig?
Would be great to get some clarification about this point.
This file needs to be modified because both Magento and WordPress have a PHP function with the same name, specifically the translation function:
function __($args);
It is not possible to have multiple functions in PHP with the same name. The only way to include the WP code base into Magento and make it available is to stop either Magento or WordPress from defining this function. The module chooses to modify the WP file instead of the Magento file.
The modification it makes it a simple one. It simply wraps the function definition in WordPress with a call to function_exists. This checks whether the function has already been defined (ie. in Magento) and if it has, it doesn't define it again. If it hasn't been defined, it defines it.
if (!function_exists('__')) {
function __($args);
}
This allows WordPress to work on it's own and when included into the Magento code. Without this modification, it is not possible to use Magento and WordPress together.
Write permissions are only required if the file does not include the modification. If the file already includes the modification then write permissions are not required. If you don't want to give write permissions on your live server, have the file modification take place either on a dev/staging server or make the file modification yourself as part of your deployment process.
I am relatively new to Wordpress.
I have two instances of Wordpress - one running on a server in prod, and the other the same exact copy that I've downloaded from the server, but running locally.
A problem I'm trying to figure out is - the one on the server is loading all the necessary JS files within the theme. However, my local running instance is only loading JS files outside the theme.
In addition, I've noticed in my local running instance - there's a no-js class added to the <html> tag, whereas this is missing in the prod instance. This leads me to believe there must be some sort of switch on the theme itself, or somewhere in the wordpress admin panel that enables or disables JS.
For some context, I'm using the minimal minimum theme: https://wordpress.org/themes/minimum-minimal/
I found out what was preventing the JS from loading - I forgot to include <?php wp_footer(); ?>
within the footer - which loads in all the remaining necessary JS, in particular if they've been imported with via wp_enqueue_script with in_footer arg set to true
I'm working on a Prestashop site and recently noticed about the SMARTY features (Menu: Advanced > Performance).
I realized that in order to show changes I made in the css, I must select one of the last two options (first one was selected by default).
Screenshot (I'm sorry the site is in Spanish)
1)Never recompile template files
2)Recompile templates when files are modified
3)Force compilation
My question is: when it comes to an online shop, wich option should I select until I finish editing the code? What's the difference between both?
It may take me a couple weeks to finish the job and I don't want to mess anything up.
Thank you guys.
When you're starting to dev onto the shop, whether it's front or back, you may have to choose the option to recompile when files are modified. I'm always choosing this option because it allows me to develop or debug some files and the server keeps serving cache files to the visitors.
Also you may have to edit the file defines.inc.php file in the config folder in order to define the _PS_MODE_DEV to true, for example like this :
/* Debug only */
if (!defined('_PS_MODE_DEV_'))
if (in_array($_SERVER['REMOTE_ADDR'], array('217.128.240.59')))
define('_PS_MODE_DEV_', true);
else
define('_PS_MODE_DEV_', false);
Doing this so you'll be able to get some logs when you're updating something. Placing your IP into the array keeps everyone safe from seeing the logs (notices for example).
In PS 1.6.
- Configure the SMARTY to "Recompile templates if the files have been updated" then deactivate the option "Smart cache for CSS"
- make the changes in your CSS files,
- delete the folders mentioned sadlyblue in comment.
- and activate again the "Smart cache for CSS" SAVE to recompile theme.
Our institute has Plone 5.0 and 4.3 running and are migrating dozens of older plone sites into them.
We have created a Diazo theme and it is hosted to provide our theme out to all plone sites. There are specific plone pages like the Login that must be changed. There are two ways we see to do this:
Portal View Customizations. Problem is we can't host this template centrally and can't change it one place to change it everywhere. This will bring maintenance issues.
Diazo. We could put all the html in the index.html and then drop code we do not need through the rules.xml. However this feels super hacky and inelegant. The index file will grow and grow in size.
What is the best approach to something like this?
My idea: (Please tell me if this good or bad)
In Diazo, the rules.xml would load a subset rules file called login-rules.xml. In the login-rules.xml, I'd put a replace rule. The replace rule would have within it all the login HTML.
You've really got two kinds of problems here.
One is deciding where to intervene for your login pages. The other is how to manage deployment of custom code.
If the changes you need are strictly ones of presentation, Diazo is a reasonable place to handle it. Remember that you may use different theme documents, with your rule set making an early decision of which theme (html) file it uses under what circumstances.
If the changes you need are beyond simple presentation and require custom logic, or if the presentation changes start to require complex custom XSLT, make the changes via view customization. But do not do that with the Portal View Customization tool. Customizations that are needed on multiple sites should go into Python packages maintained in a source-control repository like git. That goes for Diazo rules and theme files as well as templates.
You may create the skeletons for these packages with ZopeSkel or mr.bob. Use the JBOT method within these packages to customize individual template files.
Managing deployment is much easier when you're using file-system packages from a repository. You may use mr.developer within your buildout to automatically check out the current version (or a particular tag or branch) of a package when you run buildout. Then, when you need to push changes to multiple servers, you run buildout on each one and restart the ZEO clients. That may be automated with tools like Ansible. See Plone's Ansible Playbook for examples.
I've used several bits of Plone-specific jargon in the above. All of these are well-documented at http://docs.plone.org.