Uno script sh per settare i permessi di file e cartelle di wordpress

Lo script segue le pratiche consigliate per i permessi di WordPress:

  • File: Permessi a 644 (lettura/scrittura per il proprietario, lettura per altri).
  • Directory: Permessi a 755 (lettura/esecuzione per tutti, scrittura solo per il proprietario).
  • File sensibili: Come wp-config.php, impostati a 600 (solo il proprietario può leggere/scrivere).
  • Utente/Group: Facoltativamente, puoi assegnare un utente o un gruppo specifico.

#!/bin/bash

# Configura il percorso root di WordPress
WP_ROOT="/percorso/al/tuo/sito" # Cambia con il percorso corretto

# Configura il proprietario (user e group) - modifica se necessario
USER="www-data" # Utente web server (es: www-data, apache, nginx)
GROUP="www-data" # Gruppo web server

# Controlla se eseguito come root
if [ "$EUID" -ne 0 ]; then
echo "Per favore esegui lo script come root o con sudo."
exit 1
fi

echo "Impostazione dei permessi per il sito WordPress nella directory: $WP_ROOT"

# Imposta il proprietario per tutti i file e directory
echo "Imposto il proprietario a $USER:$GROUP..."
chown -R $USER:$GROUP "$WP_ROOT"

# Imposta i permessi per le directory
echo "Imposto i permessi delle directory a 755..."
find "$WP_ROOT" -type d -exec chmod 755 {} \;

# Imposta i permessi per i file
echo "Imposto i permessi dei file a 644..."
find "$WP_ROOT" -type f -exec chmod 644 {} \;

# Imposta i permessi sicuri per wp-config.php
if [ -f "$WP_ROOT/wp-config.php" ]; then
echo "Imposto permessi sicuri per wp-config.php (600)..."
chmod 600 "$WP_ROOT/wp-config.php"
fi

# Permessi speciali per wp-content/uploads (scrivibili dal server)
UPLOADS_DIR="$WP_ROOT/wp-content/uploads"
if [ -d "$UPLOADS_DIR" ]; then
echo "Imposto permessi per la directory uploads (775)..."
chmod -R 775 "$UPLOADS_DIR"
echo "Rendo uploads scrivibile da utente e gruppo..."
chown -R $USER:$GROUP "$UPLOADS_DIR"
fi

echo "Permessi impostati correttamente per WordPress!"

# Finitura
exit 0

Come usare lo script:

  1. Crea lo script:
    • Salva il codice in un file chiamato, ad esempio, set-wordpress-permissions.sh.
  2. Modifica le variabili:
    • Cambia WP_ROOT con il percorso della root del tuo sito WordPress.
    • Cambia USER e GROUP con l’utente e il gruppo utilizzati dal server web (es. www-data per Apache/Nginx su Ubuntu).
  3. Rendi lo script eseguibile:
    chmod +x set-wordpress-permissions.sh
  4. Esegui lo script con privilegi di amministratore:
    sudo ./set-wordpress-permissions.sh
  5. Verifica i permessi:
    Puoi controllare che i permessi siano stati applicati correttamente con
    ls -l /percorso/al/tuo/sito

Spiegazione dei permessi:

  • 644 (file): Lettura/scrittura per il proprietario, lettura per il gruppo e altri.
  • 755 (directory): Lettura/esecuzione per tutti, scrittura per il proprietario.
  • 600 (wp-config.php): Lettura/scrittura solo per il proprietario.
  • 775 (uploads): Lettura/scrittura per proprietario e gruppo, lettura per altri.

Nota:

  • Lo script si assume che il server web (Apache/Nginx) utilizzi l’utente/gruppo specificato (www-data).
  • Se stai utilizzando configurazioni diverse, assicurati di modificare di conseguenza i permessi o il proprietario.
  • Avrai bisogno di un’utenza con abbastanza privilegi per eseguire il file sh sulla macchina dove gira il tuo wordpress.

Come eliminare tutti i prodotti da woocommerce senza impazzire?

Minimo sforzo massima resa, in questo post spiego come ho fatto a risolvere il problema che un mio cliente aveva generato per errore. Oltre alla soluzione troverete anche l’iter che mi ci ha portato.

A seguito di un’importazione sbagliata, un mio cliente aveva riempito il suo e-commerce (woocommerce) di 2000 prodotti vuoti! Fortunatamente si trattava di un ambiente di pre-produzione e quindi non ha avuto alcun impatto sull’esperienza utente.

Tuttavia si era reso necessario un intervento massivo su tutti i prodotti, in quanto andavano eliminati del tutto dal sito internet.

Il mio cervello ha pensato subito a scrivere un poco di codice per creare uno script da lanciare in batch attraverso di un plugin ad hoc, che avrebbe dovuto esporre una pagina con un pulsante di distruzione di massa, quindi esporre un avviso per chiedere all’utente se fosse sicuro di quello che stava facendo … ma sono troppo pigro, per cui, il secondo pensiero è stato gugolare un poco (anche se in realtà uso perlopiù duckduckgo, ve lo consiglierò prima o poi assieme ad altri tool per la vostra privacy).

Dalla ricerca che ho usato wordpress how to delete all products è venuto fuori (ovviamente) la qualunque … focalizzerò l’attenzione su 2 delle soluzioni che ho trovato.

1. Aumento numero prodotti visualizzati

Parte superiore della pagina prodotti di wordpress/woocommerce

Alcuni consigliano di visualizzare più prodotti sulla stessa pagina e cancellarli massivamente

Ma questa soluzione, mostrando un numero considerevole di prodotti (anche 300), è veramente sconsigliata per tanti motivi:

  • è maledettamente lenta;
  • prevede dei tempi morti perfino lato client (javascript ci mette un po’ a spuntare tutte le checkbox!);
  • anche se il processo di cancellazione massiva viene gestito in batch, ottimizzando l’uso della memoria RAM, vi ritroverete comunque a consumare molte risorse e ad aspettare molto tempo prima che la nuova pagina venga ricaricata e possiate lanciare un altro cancella tutti.

Questa soluzione per me è quindi SCONSIGLIATA. Passiamo alla prossima

2. Query diretta al database che rimuove tutto

Non male come idea. Una bella query, fatta bene che va a togliere non solo i prodotti, ma tutte le sue relazioni con le altre risorse BASE di wordpress.

Quel “BASE” non è maiuscolo per caso. Quello che intendo impropriamente dire con risorse BASE, significa che se per qualche motivo il vostro prodotto è collegato a qualche altra risorsa introdotta da un plugin o da software di terze parti, rischiate seriamente di perdervi pezzi per strada.

Uno screenshot della soluzione così come riportata su Store App org.

Il sito storeapps.org, propone una soluzione basata su questa query:

DELETE relations.*, taxes.*, terms.*
FROM wp_term_relationships AS relations
INNER JOIN wp_term_taxonomy AS taxes
ON relations.term_taxonomy_id=taxes.term_taxonomy_id
INNER JOIN wp_terms AS terms
ON taxes.term_id=terms.term_id
WHERE object_id IN (SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));

DELETE FROM wp_postmeta WHERE post_id IN (SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));
DELETE FROM wp_posts WHERE post_type IN ('product','product_variation');

Ma ad ogni modo, lo stesso autore dopo questa query dice:

However, this is not the best way to bulk delete products

Dal sito storeapps.org

Anche se loro sconsigliano l’approccio query based, perché vogliono vendervi un plugin che fa cose, quella che dicono è una grande verità.

Troppo rischioso lanciare query nel database senza alcuna pietà. Potresti ritrovarvi con più problemi di quando avete iniziato.

Se scegliete questo approccio che io SCONSIGLIO, abbiate almeno il buon cuore di effettuare una copia di backup del database (ho scritto anche io un poco a riguardo).

3. WP CLI

La WP CLI è un software portabile scritto in PHP che vi consentirà di lanciare dei comandi sulla console per ottenere quello che volete.

Non sai di che parlo? Fidati di me, usa il metodo 1.

Il comando che ho lanciato e che ha funzionato come un incantesimo è stato quello suggerito da Ryan Steven sul suo blog.

Provare per credere:

wp post list --field=ID --post_type=product --posts_per_page=2000 | xargs wp post delete --force
Il comando che ho lanciato sul terminale dell’hosting in questione. Come è possibile vedere ho usato direttamente il file .phar.

Se avete il sito su hosting che non ha accesso alla console sappiate che potete usare lo stesso la cli, ma facendo un accrocchio che spero di avere modo di illustrarvi in qualche altro post in futuro.

Conclusioni

Se siete utenti smaliziati, dovete avere a che fare con operazioni ripetitive, containers, orchestratori (tipo kuberneetes), allora vi consiglio di studiare l’uso della CLI (proposta come migliore soluzione, la numero 3).

Se non siete utenti esperti state lontano come la peste dalle query (soluzione 2) e lanciatevi sulla soluzione 1, specie se la cancellazione massiva è da fare una tantum.

Dokan woocommerce, where is {site_name} in email placeholder

Sometimes can happen that the email sent through woocommerce have incorrect data. Where are placeholders data stored, for instance {site_name}, {site_address}, {order_number}, used in Dokan email templates? And, how to modifify {site_name} placeholder?

In my case {site_name} placeholder value was referring to an old site name, still present after a migration, due to this I bumped into the necessity of change placeholder value.

Uno screenshot del file wp-config.php dove è presente il prefisso del nome delle tabelle del database.
A screenshot WordPress wp-config.php file, where the database table prefix is defined.

To get the job done I was obliged to do the modification at mariadb/mysql database level. More specifically “{site_name}” was defined in “PREFIX_options” table, where PREFIX is your database table prefix defined in wp-config.php file at installation time.

The option to find out in my case was “woocommerce_email_from_name“, that represents {site_name} placeholder in Dokan email templates.

I came across it through phpmyadmin search functionality, searching for the name, the wrong one I want to replace, appearing on the email sent to users.

HINT!

The aim of this post is to explain how to replace Dokan email template placeholders ({site_name}), if you are trying to customize Dokan email templates, you can check out this link: https://wedevs.com/docs/dokan/tutorials/customize-e-mail-template/

An example of how Dokan is translating placeholder into bare text is the method trigger, defined in plugins/dokan-pro/modules/rma/includes/emails/class-dokan-rma-send-coupin-email.php php file:

<?php
/**
     * Trigger the sending of this email.
     *
     * @param int $product_id The product ID.
     * @param array $postdata.
     */
    public function trigger( $coupon, $data ) {
        if ( ! $this->is_enabled() || ! $this->get_recipient() ) {
            return;
        }

        $this->object = $coupon;

        if ( $data ) {
            $coupon_id      = isset( $data['request_id'] ) ? $data['request_id'] : '';
            $vendor_id      = isset( $data['refund_vendor_id'] ) ? $data['refund_vendor_id'] : '';
            $vendor         = dokan()->vendor->get( $vendor_id );
            $customer_email = $coupon->get_email_restrictions();
            $customer_email = is_array( $customer_email ) ? $customer_email[0] : $customer_email;
        }

        $this->find['site_name']      = '{site_name}';
        $this->find['vendor_name']    = '{vendor_name}';

        $this->replace['site_name']   = $this->get_from_name();
        $this->replace['vendor_name'] = $vendor->get_name();
        $this->replace['coupon_id']   = $coupon_id;

        $this->setup_locale();
        $this->send( "{$customer_email}, {$this->get_recipient()}", $this->get_subject(), $this->get_content(), $this->get_headers(), $this->get_attachments() );
        $this->restore_locale();
    }

In particoular, pay attention at these two lines:

...
$this->find['site_name']      = '{site_name}';
...
$this->replace['site_name']   = $this->get_from_name();
...

The get_from_name method is defined in a superclass and is the function in which the substitution is done.

I strongly suggest you to explore source code through Visual Studio Code or an equivalent product, to better understand how your specific case works.

Fell free to post a comment to submit your case.