DeutschEnglish

Submenu

 - - - By CrazyStat - - -

9. June 2017

Automatically run WP-CLI as the correct user

Filed under: Linux,Server Administration,Wordpress — Tags: , , , , , , — Christopher Kramer @ 19:04

You are root, your php runs with a different user for each site / customer e.g. using PHP-FPM. And these users don’t have a shell assigned. So how can you easily run wp-cli with the correct user to avoid permission denied-problems?

This is how: Define an alias for wp in your shell config, e.g ~/.bash_profile like this:

alias wp='sudo -u `stat -c '%U' .` -s -- php /usr/local/wp-cli.phar --path=`pwd` '

This will first run stat -c %U . to get the owner of the current folder. Then it will pass this to sudo to execute the command as this user. You might need to adjust the path to the phar-file.

Relogin so the alias takes effect and have fun! 🙂

Now when you are in the folder of some site and run wp-cli with the wp command, it will always automatically run with the user that is the owner of the wordpress-folder, which should be the user assigned to this site.

This is tested on a Debian Wheezy system. On FreeBSD, you would need to adjust it slightly:

alias wp='sudo -u `stat -f '%Su' .` -s -- php /usr/local/wp-cli.phar --path=`pwd` '

Let me know if this saved your day or you still have some problems.

Recommendation

Try my Open Source PHP visitor analytics script CrazyStat.

21. May 2015

wp-cli: syntax error, unexpected ‘?’, error connecting to the database

Filed under: Server Administration,Windows,Wordpress — Christopher Kramer @ 10:55

Running wp-cli on a website that was set up by somebody else resulted in a strange error:

PHP Parse error:  syntax error, unexpected '?' in phar:///usr/local/wp-cli.phar/php/wp-cli.php(23) : eval()'d code on line 1
Error:
<h1>Fehler beim Aufbau der Datenbank-Verbindung</h1>
...

The database settings in wp-config.php were all correct and WordPress was also working, so this did not seem to be the problem. In the end, I found out the reason was a byte order mark at the beginning of wp-config.php that had been inserted probably by Windows Editor. To solve the issue, the easiest way is to open the file in a good editor, for Windows I recommend PSPad, copy everything into the clipboard (CTRL +A, CTRL + C), create a new empty file (CTRL + N), paste everything (CTRL + V), save it (CTRL + S) as wp-config.php and upload the file.

 

26. February 2013

Montezuma WordPress Theme: Solve Inline CSS

Filed under: PHP,Wordpress — Tags: , , , , , — Christopher Kramer @ 18:12

I was recently asked, why CSS changes within admin panel of the Montezuma WordPress Theme were not reflected on the frontend.

I found out that there is an issue with Multisites, but no solution. So I digged into the code to solve the issue. As I think it might be useful for somebody, I post here what I found out.

if you are not interested in technical details, just look for what I highlighted 😉

Montezuma theme uses inline CSS

If you look at the HTML Source of your site, you will find the whole CSS inline along with this text:

/*************************************************************************
Default CSS served INLINE because wp-content/uploads is not writable.
This will change once wp-content/uploads is writable
**************************************************************************/

So the issue seems to be simple: Just correct permissions. Something like this:

chown www-data:www-data wp-content/uploads

Unfortunately, this was not the issue here. So why does Montezuma fail to place the static CSS file in wp-content/uploads?

Invalid file type

It took me a while to figure out what Montezuma does. In save_css_file() in includes/admin.php, it uploads/stores the theme’s css using wp_upload_bits(). The first problem in the theme is that it does not catch the resulting error while doing this. It should at least print it somehow. In this case, this would result in “Invalid filetype” (in your language).

So wp_upload_bits() calls wp_check_filetype(). This will call get_allowed_mime_types() for a list of allowed mime types. And this looks like this:

function get_allowed_mime_types() {
        return apply_filters( 'upload_mimes', wp_get_mime_types() );
}

So it calls wp_get_mime_types() for a list of mime types. This will again apply a filter on a list of arrays, which in fact contains css. This is good news, because we want to store a css file…

So one of the filters kicks “css” out. And the short story is that it is upload_mimes. The upload_mimes filter uses a list of allowed extensions that can be edited by the user!

To edit it, open http://example.com/wp-admin/network/settings.php in your browser.  The list of allowed filetypes for uploads is quite at the end of the list of settings. Just add “css” here (space-separated).

I think Montezuma should better overwrite the upload_mimes filter with one that allows css.

If you now save your Montezuma settings, it should successfully create a file http://example.com/wp-content/uploads/montezuma/style.css

But in a Multisite setup, this is not the end of the story.

Montezuma uses CSS per site (in a Multisite setup)

With a multisite setup, it depends in which site-backend you change the Montezuma css. If you login one site, it will create the css for this site. If you log into another site, it will create the css for this site.

So you need to change the css in the backend of every site.

So let’s assume you have a site “de” and a site “en”. Then go to http://example.com/de/wp-admin/themes.php?page=montezuma and change the CSS in the Montezuma settings.
This will create a file like: http://example.com/wp-content/uploads/sites/1/montezuma/style.css

Then log into the next site http://example.com/en/wp-admin/themes.php?page=montezuma and edit the css there as well.
This will create a file like: http://example.com/wp-content/uploads/sites/2/montezuma/style.css

Then the css as you edited it should be used in the frontend.

I guess Montezuma should add an option to use a global css for all sites.

Update: Similar problem: Google Webfont is not loaded

The theme allows you to easily use a google webfont. But it does not load?

The problem is almost the same: It fails writing the .js-file. So go into the network-settings and add “js” to the list of allowed extensions, save the Montezuma settings and it should work.

 

26. April 2012

How to include CrazyStat in WordPress

Filed under: CrazyStat,PHP,Wordpress — Tags: , , , , , — Christopher Kramer @ 00:52

Of course it is possible to include CrazyStat in wordpress. I will describe here how it can be done. This approach assumes you have your own wordpress installation and can edit templates. It might not work this way if your blog is hosted on wordpress.com or similar. But I guess using CrazyStat in these cases would still be possible. Contact me if you need to know how and I will have a closer look.

So I assume you have a running wordpress installation and installed CrazyStat like described in the readme (at least steps 1-6 of quick install instructions). I assume you have a backup of your wordpress installation (at least the themes folder).

So the question is where to put the include code:

<?php @include_once("stat/src/include.php"); ?>

Log into the wordpress admin panel and click appearance/editor (German: Design/Editor). Make sure you selected the correct theme in the dropdown menu on the top right.

In case you do not want to use a counter

Click on “footer.php” on the right. You will see some HTML / PHP code in the editor. Put your cursor just before </body> (which should be quite at the end).  This is the best place to insert the CrazyStat code:

<?php @include_once("stat/src/include.php"); ?>

The path is seen from the wordpress root-directory. This code assumes you installed CrazyStat in the wordpress root-directory under “stat”. In case you installed it one level higher, you would need to use:

<?php @include_once("../stat/src/include.php"); ?>

Save your changes.

You might also need to adjust $config_rel_path. See config-documentation for details.

In case you want to use a counter

In this case, you’d need to find the place in your template where you want to place the counter. This should normally be somewhere after <body> in header.php, before </body> in footer.php or in sidebar.php. Unfortunately you need some HTML experience to find the correct place here. Use the same code as above.

In case you have problems

Please ask in the CrazyStat support forum in case you have problems or questions (no registration required at the moment!).

I hope I could clarify this for some people. Maybe I will do a wordpress plugin sometime. If you think this would be a great idea, tell me in the comments.

Alternative option: Use the WordPress plugin mzz-include-CrazyStat (Update 2017-02-17)

The problems with the solution described above are:

  • Whenever the theme is updated, the change of the footer.php might get lost.
  • If you switch to another theme, you need to add the CrazyStat code again.

To solve these problems, CrazyStat user Morgan Jassen developed a small helper plugin that just inserts the include code:

Find it here: https://github.com/mjassen/mzz-include-crazystat

I just found this today and have not tried it yet, but think it is the better option. Thanks, Morgan!

15. February 2012

WordPress: Frontend and Backend in different Language

Filed under: Wordpress — Tags: , , , , , — Christopher Kramer @ 23:45

In case you want to use a different language for the wordpress frontend (your blog) and the backend (admin panel), here is a tip how it can be done.

Step 1: Set frontend language

Configure the language of WordPress for the language you want your frontend in. You do this in wp_config.php using the constant WPLANG:

define ('WPLANG', '');

This unsets the language, meaning the frontend will be English. This also works if you use a localized version of wordpress. If you want to set another language, do so:

define ('WPLANG', 'de_DE');

This would set the language to German. You need to have a corresponding .mo-file in wp-content/languages (in this example, wp-content/languages/de_DE.mo).

Step 2: Set the backend language

Step one will also affect the backend. If you want to have the backend in another language, there is a neat little plugin which changes the backend language for you, which I found on this forum.

<?php
/*
Plugin Name: Change backend language
Version: 0.5
Plugin URI: http://forum.wordpress-deutschland.org/konfiguration/32642-frontend-soll-englisch-sein-adminbereich-deutsch-engl-od-deut-download-nehmen.html
Description: Changes the backend language
Author: Oliver Schlöbe
Author URI: http://www.schloebe.de/
*/

function os_setAdminLang($locale) {
    if( WP_ADMIN === true ) {
        $locale = 'de_DE';
        return $locale;
    }
}

add_filter('locale', 'os_setAdminLang', 1, 1);
?>

This changes the backend language to German. In case you want another language, change ‘de_DE’ to the desired language in line 13. You need a corresponding .mo-file just like for the frontend.

Save this as something like wp-content/plugins/change_be_language.php

Then active the plugin in your backend and your backend will turn into the language you set.

Attention: Make sure there are no extra spaces in the plugin-file. Especially at the end, some editors tend to add spaces or line breaks. This will result in problems (headers cannot be sent etc.).

Hope someone finds this useful.

Update: Just found out, that the author wrote a blog post himself about this (English text at the bottom of the page)…