Risultati della ricerca per 'Wordpress database api plugin'

Stai vedendo 15 risultati - da 31 a 45 (di 55 totali)
  • Prima di fare l’aggiornamento manuale, come descritto nella pagina del link, avresti già dovuto avere tutti i plugin disattivati, compreso il tema, attivandone uno di default della serie Twenty di WordPress.
    In questa situazione – che virtualmente rappresenta un’installazione base senza plugin e con il tema di default – tutte le funzionalità base devono esserci e comparire per forza.
    È qui che ti devi soffermare, come già spiegato:

    – Se tutto è come dovrebbe essere, riattivi il tema e i plugin uno alla volta, controllando attentamente, riuscendo così a capire quale causa il problema.

    – Se invece, pur in quella situazione base, il problema c’è ancora, allora non è causa diretta di WordPress, aprendosi diverse possibilità “esterne” che è difficile ipotizzare non conoscendo la tua installazione, da problemi di configurazione sul server a un banale problema di permessi, da file mancanti o trasferimenti incompleti, fino a modifiche (eventualmente anche sul database) che ne hanno compromesso la funzionalità. Controlla anche l’.htaccess.
    Per individuare eventuali errori sul server devi guardare il log degli errori e/o rivolgerti al tuo provider del servizio.

    @hpl80, cambia anche le chiavi segrete https://api.wordpress.org/secret-key/1.1/salt/
    Immagino che tu abbia già scansionato l’intero sito e controllato il database (previo backup). Leggi qui.
    Apri un ticket con il tuo host anche per questa cosa, perché se la backdoor è a livello di server è possibile che infetti altri siti e in quel caso servirà poco pulire da parte tua, cambiare tutte le pw e adottare le altre misure necessarie, perché finché c’è la falla tornerà, quindi per un po’ dovrai tenerlo controllato giornalmente, almeno finché non cambi server e/o il tuo provider non aggiusta la falla (se è del server…).

    @tonicopi, è un codice che nega l’accesso al wp-config.php ed è una misura di sicurezza in più, ma in teoria non ce ne sarebbe bisogno se i permessi sui file sono corretti.
    Non ho mai usato WordFence, ma naturalmente dovresti evitare di aggiungere manualmente quelle misure di sicurezza già previste dal plugin.

    • Salve,

      ho cercato di capire se fosse questa la sezione giusta, spero di non aver sbagliato.
      Premetto di essere uno smanettone ma non un professionista del settore.

      Praticamente, sto cercando di capire come dovrei creare un database su wordpress ed inserirci valori che poi tramite il ‘cerca’ mi trova e mi stampa a video.

      Es:

      Inserisco un gatto x:
      colore: bianco
      nome: fuffi

      Successivamente lo cerco tramite: cerca tutti i gatti di colore bianco e mi spuntano tutti i gatti di colore bianco.

      Esiste un plugin per fare tutto questo?

      Grazie

    Forum: Varie ed eventuali
    In risposta a: Normativa GDPR

    Salve
    Anche io condivido la preoccupazione di Cristiano: poca informazione su come e cosa bisognerà impostare su un sito WordPress per essere a posto con la GDPR, che di fatto non si capisce neanche bene cosa voglia che si faccia su un sito.

    Se può servire ho fatto alcune verifiche su alcuni plugin per capire se “lasciavano tracce dell’utente” sul database di WP o nei file del sistema.

    Ovviamente ogni visitatore lascia registrato il proprio IP: l’indirizzo IP segnato dal log nel momento della visita può essere oggetto di richiesta di oblio? E’ demenziale… anche perché è perfettamente anonimo… e spesso dinamico.

    Comunque per capire cosa viene tracciato, almeno in parte, su un mio sito ho installato WP Security Audit Log. Vedrò se serve

    Al momento:

    Contact Form non lascia nessuna traccia nel database del sito e in pratica funziona come una qualsiasi email.
    Ovviamente per il visitatore che lo usa si avrà un tacciamento dell’IP per il solo fatto che ha aperto il mio sito.

    Give (Donazioni)
    Registra tutti i dati del donatore nell’apposito pannello di gestione e quindi, ovviamente, nel database. Avrei piuttosto delle perplessità in merito al valore fiscale di tali registrazioni: si può applicare l’oblio se richiesto a dati relativi a una donazione?

    WooCommerce
    Ovviamente registra tutto e tutto è facilmente reperibile nel pannello di gestione etc.
    Ma anche qui, in caso di richiesta di oblio da parte del Cliente, fino a che punto è possibile applicarla? Sono dati fiscali o no? se sono fiscali per legge vanno conservati 5 anni.

    MailPoet (Newsletter)
    Va da sé che registra indirizzi e-mail, nome, cognome, clic, aperture, etc. Bisognerà conservare religiosamente le email con cui gli utenti si sono iscritti, ma nelle pagine di gestione del plugin si trova tutto.

    Altre domande
    Bisognerà conservare tutti questi dati fuori dal sito, su altri supporti?
    Non tutto è immediatamente estraibile…
    Bisognerà conservarli criptati?
    Affittare una cassetta di sicurezza in banca?

    Se qualcuno ha dei lumi ben venga…
    Grazie

    Chi ha creato la discussione micheleadmin

    (@micheleadmin)

    Intanto grazie per la risposta… e il benvenuto.

    <è necessario capire se e quali plugin sono stati usati fin’ora per generare quel campo scadenza>

    Non ho usato alcun plugin, ma il campo è stato generato e riempito via MySQL, tramite uno script che ha inserito i dati nei campi del database di WordPress (tabella usersmeta, appunto) a partire da un db esterno.

    <https://it.wordpress.org/plugins/paid-member-subscriptions/&gt;

    Ho installato e provato questo plugin. Ho il problema di non poter fissare la data di scadenza nelle caratteristiche dell’abbonamento quando vado a crearlo, ma solo una durata. Non posso poi modificare il parametro “Expiration date” in un secondo momento per tutti gli utenti di una data categoria in blocco, ma dovrei farlo manualmente per le migliaia di utenti attualmente registrati..

    Inoltre per questo plugin dovrei trovare un workaround per i pagamenti, che attualmente devono essere effettuati necessariamente via bonifico o bollettino postale. E su questo purtroppo ho dei vincoli amministrativi (è per una associazione). Attualmente l’amministratore mi manda l’elenco degli abbonati in regola e con una query io posso aggiornare gli utenti che hanno accesso ai contenuti riservati lavorando sul quel campo data della tabella usersmeta. Potrei settare l’abbonamento come gratuito e lavorare io dal backend per aprire e chiudere gli accessi. Esiste un metodo più smart??

    Moderator Cristiano Zanca

    (@cristianozanca)

    Benvenuto nel forum @micheleadmin

    Nel database, alla tabella usersmeta, esiste un campo data con la data di scadenza dell’abbonamento per ogni utente.

    prima che di agire direttamente sul database è necessario capire se e quali plugin sono stati usati fin’ora per generare quel campo scadenza

    Il consiglio è di provare questo plugin

    https://it.wordpress.org/plugins/paid-member-subscriptions/

    Aggiornaci

    • Buongiorno, sto cercando di completare il trasferimento in remoto di un sito wp che ho realizzato in locale.

      ho eseguito tutte le procedure, ovvero:

      – esportare db da locale e importarlo in remoto su db libero (aruba)
      – importare file e cartelle su ftp aruba in sottocartella
      – modifica site url e home nelle wp-option del database
      – modifica file wp-config

      fatte queste procedure, quando vado a http://www.miosito.com/cartella/wp-admin mi invita a installare nuovamente wordpress, ma è già installato!

      inoltre, se può essere d’aiuto, prima di questo punto mi segnalava vari errori riguardo a dei plugin, o addirittura non mi prendeva bene l’host nonostante l’avessi scritto correttamente. Ho dovuto usare il file wp-config-sample altrimenti mi dava sempre errore.

      Ora il punto è che apparentemente non mi da più errore ma vorrei capire se ha senso reinstallare wordpress se in realtà dovrebbe aprirmi la pagina di login.

      attendo vostre delucidazioni…
      grazie

      Rob

    • Salve a tutti…
      e spero di porre alla vostra attenzione un argomento cruciale: la sicurezza…
      spero anche non me ne vogliano i moderatori se sarò troppo prolisso…
      essendo novizio: se sbaglio mi correggerete…

      nel autunno 2016 ho subito un primo attacco bruteforce ad un mio sito WP…
      fortunatamente (tenevo costantemente sotto controllo le statistiche ed i tentativi di accesso ) me ne sono accorto e l’ho stroncato mettendo rapidamente in atto le contromisure …
      purtroppo a gennaio 2017 ho subito un secondo attacco e questa volta con conseguenze catastrofiche…
      sono riusciti ad impossessarsi dell’accesso agli account mail e perfino a miei dati c/c e carte di debito…
      i danni a livello bancario sono stati modesti, ma il mio lavoro con wordpress è andato in fumo in un attimo… sono riusciti a sottrarmi il controllo dei DNS (reindirizzandoli su siti facks) e per recuperarli dopo 3 denunce alla polizia postale ci sono voluti due mesi di lotta con i providers-registrants i domini per riprendere il controllo del pannello le passwords e ripristinare il tutto…
      un paio d’anni di lavoro polverizzati e uno stop di oltre 6 mesi prima di recuperare un minimo di produttività… un vero incubo !

      Certamente ho commesso diversi errori…
      ad esempio è sbagliato pensare : “posso anche lasciare le porte aperte tanto non hanno nulla da rubare” … ho constatato che purtroppo c’è al mondo chi lo fa per vendetta o per pura idiozia…
      quindi spesso il “ladro/delinquente” non si limita a entrati in casa e derubarti ma si diverte a distruggere tutto quello che può…
      sbagliando si impara…
      sulla base della disastrosa esperienza sto riconsiderando tutti gli aspetti inerenti la sicurezza che coinvolgono il mio lavoro con wordpress.
      Vi espongo quindi i miei ragionamenti per avere, da chi ne sa più di me, una conferma : se mi sto muovendo correttamente o se sto ripetendo errori che potrei pagare di nuovo in futuro a caro prezzo e stress.

      Dal momento che non si può considerare a rischio 0 la eventualità che qualcuno riesca a prendere in qualche modo controllo della nostra installazione WP (database & cartella public_html; Hosting/pannello di controllo ) o inquinare il database, assumo che il backup di tutti i dati debba necessariamente essere effettuato con il massimo scrupolo e frequenza. Spero che su questo la maggiorparte di voi concordino…

      se il backup viene effettuato sulla stessa macchina fisica su cui sono presenti i vostri dati in caso di guasto dell’ HD o del server (remota ma non impossibile), ovvero, in caso di guasti tecnici… siamo fregati.

      Inizialmente ho pensato quindi a scaricare i backup sul mio PC locale in ufficio …
      a parte il fatto che la sicurezza su un PC usato normalmente in un normale ufficio (dove tranquillamente e quotidianamente si aprono mail ed allegati (e magari si naviga sul web) è molto labile, anche provvedendo in locale a fornirsi di una macchina configurata in modalità server e con tutti i crismi della sicurezza applicabili …
      ci si scontra con la realtà dell’ obsolescenza delle reti-dati-ADSL Italiche…
      in alcune località anche le prestazioni di alice 20mega sono un sogno…
      chi ha provato a fare un download ed un upload di un Backup di un sito di medie dimensioni con le correnti velocità di upload si sarà accorto che ci vuole una notte intera… e se la connessione cade… si ricomincia come nel gioco dell’oca..
      fino a prima del’ attacco avevo un hosting shared con discrete prestazioni e ottimo rapporto prezzo qualità…
      ora sto facendo dei test utilizzando due distinti hosting VPS che alla fine mi costeranno poco di più…
      sul primo gira solo l’installazione “in produzione”…
      sul 2° vengono stokati i backup e gira un clone della installazione “in produzione” in modalità che non è accessibile al pubblico…
      qualcuno potrebbe dire: “perché non scarichi i backup su un cloud (dropbox vs google vs mega, tanto per non fare nomi) ? ”
      perché sul 2° server VPS ci faccio girare un clone identico (ricavato ed aggiornato dai salvataggi frequenti della 1°) che mi permette di testare prima di implementarlo sull 1° VPS (quello attualmente “in produzione”) tutti gli aggiornamenti che dovrò effettuare…
      chi non ha mai avuto dei guai dopo aver aggiornato un plugin o un tema o anche semplici parti di codice : alzi la mano !
      Le comunicazioni fra i due server che fisicamente sono separati in luoghi. ovvero in data-center diversi, viaggiano su fibra ottica (verae reale ! …non quella che reclamizzano in Italia e che di ottico non ha proprio nulla) a 400MB costanti e garantiti …
      il che vuol dire che un backup e/o restore comportano solo qualche minuto.
      Posso inoltre controllare tutto (compreso il cpannel e la WP Admin dashboard), con un qualunque portatile, anche con connessioni precarie e/o lente, tramite NoMachine o VNC… da qualunque luogo io mi trovi al momento … anche su Italo e/o frecce FS e/o autostrada.
      Al momento i test mi danno risultati più che soddisfacenti…

      Che vi sembra di questo modus operandi ?
      Qualcuno di voi ha suggerimenti e/o esperienze in questo campo e sulla base del mio ragionamento ?
      In base alla vostra esperienza: c’è di meglio ?

      Ringrazio tutti per la pazienza…

      • Questo topic è stato modificato 8 anni, 6 mesi fa da altg58.
      • Questo topic è stato modificato 8 anni, 6 mesi fa da altg58.
      • Questo topic è stato modificato 8 anni, 6 mesi fa da altg58.

    Ciao truscoboss,
    probabilmente quello slug è in qualche modo salvato nel database: potresti provare a installare un plugin per la pulizia del database (ad esempio https://it.wordpress.org/plugins/wp-optimize/) e vedere se risolve il problema.
    Ricordati di fare un backup prima!

    L’alternativa sarebbe dare un occhiata direttamente al db per cercare questo slug e capire come intervenire nello specifico.

    Moderator Guido Scialfa

    (@wido)

    Non so in merito al link che indichi ma a questo punto conviene che fai un backup,

    Rimuovi i files dall’ftp e li ricarichi exnovo per quanto riguarda WordPress, riguardo invece ai files interni a wp-content ci vorrebbe da far fare uno scanning e dove è possibile riscaricare nuovamente i plugins ed i temi e caricarli via ftp così che i sorgenti siano puliti.

    Per la directory di upload, una ricerca a tappeto di eventuali files che possono contenere scripts php o di altro tipo. Ad esempio verifica che non ci siano files .php, bash .sh o che altro al suo interno, non sai mai che tipo di attacco puoi avere, se lato Wp o da un server compromesso. (Ipotizzo).

    Una ricerca anche di eval e/o cose come = $_POST = $_GET per eventuali assegnazioni di valori sui files di plugins e temi. Per i files di Wp una volta reinstallati non mi preoccuperei molto.

    Il controllo del database è una pratica che dovrebbe essere fatta, quanto meno per capire se il problema risiede anche lì o meno. Se incontri contenuti come ad esempio scripts interni al contenuto del post, la tabella post_content, url guid con parametri aggiuntivi non propriamente consoni.

    Inoltre per approfondire cercherei anche in rete questa cosa dei files con suffisso .suspected ed andrei a leggere i forum di supporto dei plugins e del tema in uso.

    Una volta reinstallato tutti i sorgenti puliti provvederei all’installazione di WordFence e metterei in sicurezza alcune cose per il CSRF, CSP, aggiunta della lista delle botnet conosciute, fare in modo che la directory di upload non possa eseguire scripts php etc… alcune cose le fai con il plugin sopra indicato altre invece puoi vederle qui https://pastebin.com/u/hackrepair come ad esempio la lista dei bad ip https://pastebin.com/5Hw9KZnW

    Successivamente, bloccherei alcune cose di WordPress ad esempio, hai necessità che le rest api siano accessibili? Necessità che XMLRPC sia attivo? Puoi disattivare anche la registrazione da wp-admin con https://wordpress.org/plugins/disable-wp-registration-page/ e/o https://wordpress.org/plugins/disable-register/ che ti previene anche l’accesso e l’invio di query strings alla pagina wp-login.php.

    Moderator Gloria Liuni

    (@glorialchemica)

    Ciao @gabriele732002;
    e benvenuto sul forum! 🙂

    Ho dato un’occhiata al forum di supporto del plugin per capire se il problema fosse già stato posto. Ho trovato questo topic, che credo possa essere un buon punto di partenza.

    Il topic indica che il problema nasce dal fatto che il Database di WordPress non è allocato sullo stesso server di quello di Joomla!.

    Se questo è il tuo caso, puoi procedere come suggerito nel topic. Personalmente quando ho testato il plugin, ho fatto copia in locale del sito Joomla! con l’aiuto di Akeeba Backup. Avendo in locale entrambe le installazioni (WordPress e Joomla!) non ho avuto problemi a importare il database.

    Facci sapere

    Forum: Varie ed eventuali
    In risposta a: Help! Articoli spam

    Ciao @daniel9366,
    molto probabilmente qualcuno è riuscito a ottenere le tue credenziali e adesso sta utilizzando WordPress per pubblicare i propri contenuti.

    Complimenti per aver tentato disattivando i vari plugin ma in questo caso specifico ci sono molte altre azioni che devi svolgere:

    • cambiare le password (del tuo utente e del tuo database)
    • aggiornare le SALT nel tuo wp-config.php
    • magari installare un plugin come WordFence o iThemes Security
    • se attive, disabilitare le REST API che forse l’attacco arriva in questo modo

    Con tutte queste cose dovresti essere in grado di impedire a utenti malevoli di pubblicare nel tuo blog.

    A quanto ho capito l’utente che sta pubblicando gli articoli spam è il tuo stesso utente giusto? Se così non fosse, oltre alle operazioni precedenti, elimina anche qualsiasi altro utente che non hai creato tu stesso.

    Ultimo consiglio, proprio come abbiamo discusso in quest’altra discussione, se stai utilizzando il tuo utente Amministratore anche per pubblicare i tuoi articoli è consigliabile creare un utente con ruolo Editore e trasferire a questo tutti gli articoli.

    In questo modo nasconderai il nome del tuo amministratore e renderai la vita più difficile a chi cerca di attaccarti.

    Non esitare a portare avanti questa discussione, a presto.
    Andrea

    Ciao @fabio50,
    l’approccio di avere un Editore è proprio questo. Proprio dal nome di questo ruolo si capisce che tutto il suo potere viene delegato alla gestione editoriale della piattaforma e proprio per questo non gli è possibile installare plugin o temi…

    Onestamente non capisco la difficoltà nella creazione delle gallerie…

    È un plugin esterno oppure è la funzionalità interna a WordPress che stai cercando di utilizzare e per qualche strano motivo non funziona? Se fosse la prima le soluzioni sono due:

    • o entri come amministratore ogni volta che devi creare una nuova gallerie, salvi ed esci
    • oppure con plugin come Members aggiungi le capability necessarie per la creazione della galleria al tuo utente Editore e il gioco è fatto

    Ovviamente tutto questo dipende da quanto di frequente hai bisogno di creare una galleria. Se si tratta di un’attività che svolgi un paio di volte al mese io lascerei tutto in mano all’amministratore ma se più frequente allora renderei più potente il mio Editore.

    Rispondendo invece al tuo ultimo commento: “non so se vale la pena mantenere due utenti” la mia risposta è assolutamente sì!

    Non è tanto un carico o qualcosa che puoi evitare, se vuoi mantenere il tuo sito più al sicuro possibile da attacchi (oltre a seguire i suggerimenti precedenti) essere in grado di mantenere il nostro amministratore il più nascosto possibile è un altro vantaggio che non possiamo ignorare.

    Comprendo che la creazione di gallerie può essere un fattore importante, ma al posto di “promuovere” un utente ad Amministratore io aggiungerei le capability necessarie ma manterrei l’Editore soltanto in grado di gestire la parte editoriale del mio blog.

    So che possono sembrare soltanto pensieri complicati, ma è la stessa cosa che facciamo tutti quelli che tengono alla sicurezza della propria piattaforma (o almeno quelli che conoscono questa possibilità).

    Lo scopo di avere un Editore che non ha poteri sulla gestione della piattaforma (utenti, temi e plugin principalmente) ci mantiene al sicuro perché anche se qualcuno sarà in grado di rubare le credenziali di questo utente, una volta entrato non potrà fare niente di grave, alcune delle cose che non potrà fare:

    • creare nuovi utenti per i propri scopi
    • installare plugin malevoli o modificarli
    • modificare i file del tema per aggiungere il proprio codice
    • ottenere le credenziali del database…

    Sono sicuro che ci sono molti altri tipi di attacchi dai quali ci potremmo proteggere se utilizziamo il nostro Editore come utente pubblico 😉

    Spero di aver chiarito meglio la situazione e la necessità di mantenere due utenze distinte. Non esitare a rispondere se rimasto con qualche dubbio.
    Andrea

    Ciao @darkie78,
    il problema di cui ci parli mi sembra molto particolare e soprattutto non mi è mai capitato prima d’ora…

    Hai provato a disattivare uno ad uno i plugin e controllare se fosse qualcuno di questi che va in conflitto con la creazione di un nuovo utente?

    Nella mail che viene inviata la URL del sito è giusta? Hai provato a creare un utente senza impostare per lui la password? In questi casi WordPress invierà una mail con un link “di attivazione” permettendo all’utente di creare la sua password direttamente con WordPress.

    Ultimi due consigli, controlla il tuo wp-config.php e assicurati che i dati del database siano quelli corretti. Non dovrebbe essere questo il problema ma non si sa mai.

    Prova a scaricare questo script per il search replace ed esegui un ultima volta il cambio dal vecchio al nuovo dominio, magari ci sono alcune informazioni che non sono state aggiornate dati gli errori che hai avuto con Tophost.

    Spero di averti dato qualche spunto che ti aiuti a risolvere la situazione e non dimenticare di tornare sul forum a farci sapere come e se hai risolto 😉

    A presto,
    Andrea

    Moderator Guido Scialfa

    (@wido)

    Ciao @actiwork,

    Innanzitutto prova a disattivare tutti i plugins ed attivare il tema di default ( previo backup completo di database e files ).

    Vedi se così il problema si risolve. Se si risolve è colpa di un plugin o del tema. Intanto capisci se c’è qualcosa che non va lì.

    Il tuo file .htaccess è corretto? Provato ad aggiungere le regole base di WordPress per i permalinks e nulla più? Ovviamente devi aver attivo i permalink e non la struttura di default.

    Ad esempio:


    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress
    `

    Ps. Modifiche ai files vanno effettuate solo via ftp.

    • Questa risposta è stata modificata 9 anni fa da Guido Scialfa.
Stai vedendo 15 risultati - da 31 a 45 (di 55 totali)