Martin999

Hey Pascal, thanks a lot.

“The Disable Embeds plugin is very simple, stable and does not require a lot of updating.
It contains no real attack surface for intruders.”

That’s what I supposed, o.k., “done”.

“I recommend you to change your passwords, and scan your site for any installed backdoors. This will be much more fruitful than checking old plugins.”

Yes, you think intuitively right (how do you know?). There are several strange cryptic sounding “fdvor8”.phps ect. in main folders, and some of them recognized my PC-scanner as “Backdoor.PHP.Workshell.EH” (whatever a backdoor means).
There are also added “index2.php”, “xindex.php” in many folders, changed index.php and htaccess appear in many folders.

“Since you mentioned UpdraftPlus, it contained a few security vulnerabilities in the past. Might be good to verify you were not on one of those versions.”

Again you could be right, though I’m a little bit shocked about UpdraftPlus… The Malware-Scan of my hoster found in every site among other things the same following issue:

…plugins/updraftplus/central/listener.php
#######################################
Changed -> 13.06.2020 14:45:36 +0200

Zeile -> SuchMuster -> FUND (Max. 300 Zeichen, gekuerzt, escaped…, angezeigt maximal: 20)

73 -> if (!empty($_GET[.*]) &… -> if\(!empty\(\$_GET\[‘login_id’\]\)\&\&is_numeric\(\$_GET\[‘login_id’\]\)\&\&!empty\(\$_GET\[‘login_key’\]\)\)\{

Thanks for your fast response.

I forgot to mention one important thing:
For both variants, “article star rating” and “customer review rating”, I need to display the “aggregateRating”, i.e. the average score of all ratings. Is this possible?
If yes, I will install the plugin and test all features.

78 5-star-ratings and only one bad rating for your plugin, this is really remarkable. Usually there are always a handful of trolls…

Maybe they should hire you for support ??

Take some good photos from me… ah, we are in diffeent countries… ?? what a pity…

It’s not an Updraftplus issue I guess. I haven’t migrated to https until now, but changing the http-protocol should be reflected by changing your wordpress URLs in your general settings I supposed, not only because this influences your login.

Did you change both URLs now to http

s

, “WP URL” and “Site URL”?

Maybe a guy from UpdraftPlus can confirm my idea.

I was migrating from a https site to a http site. If that’s what is causing this how do I fix it?

Did you change the WordPress and Site URL in your General settings to https
and did you login then with https?

Apologies for the delay. This does appear to be a different issue to the redirection issue (in that case, the login page reloads).

When changing the database information, did you also change the database encryption salts/security keys in wp-config?

Yeah, doesn’t seem to be the “redirect loop”, because it was not just a login page reload. I always got a “red error” and didn’t leave the login page – just like typing the PW wrong.

When changing the database PW I did not change anything else in wp-config. The keys there are still the same since WP installation.

Even if not causing the login redirect issue, is it possible that the https/http-issue can cause the described kind of login failure, even after deleting cache/cookies?

Hi,
hm… after failing Login with unchanged WP-PW I tried it
– with deleted cookies/cache and https via SSL-exception in browser (Firefox)
– with deleted cookies/cache and also deleted SSL-exception, i.e. with http
– different browser which never had https by SSL-exception

After typing in the PW and “Enter” I always got the same result:
I stayed on the login page, the page was “shaking” two seconds to the left and right and a red vertical line telling me that something is wrong.

Does this sound like the “WP login redirect loop issue”?

Hi,
lost Password link worked. I can login now in WP again. Tried it also sucessfully with a different profile in FF and with a different browser (Chrome). The new PW works.

I did the “lost pw link” without SSL-browser-exception, i.e. I deleted it in my browser and used https://…login.php (not https, which my site does not have).
I deleted all cookies before.

Then I deleted the “old” files, like UpdraftPlus recommended in the backend and I made a manual backup with UpdraftPlus.

Hope this helps to find the exact issue or at least narrowing down the possibilities.

Really curious about your opinion now.

Hi DNutbourne,
thanks for your answer.

The log shows that the restoration was successful (sometimes logging in fails if the database restoration fails at a certain point)

I understand. No, the whole process went smoothly, ending with a success message.
But just one or two seconds after the success message WP told me that my session has ended and invited me to login again. Strange for me because my session was very fresh. Since then I cannot login with the WP Password.

Do you had already similar cases, saying from your experience what might be the reason for being thrown out from WP just after restore? Searching in forum doesn’t give me hints.

Not sure if it may be important, but though my site has no SSL/https, I use to work on backend with https by browser exception. So when starting the restore UpdraftPlus gave me a warning (“backup has http, right now there is https”).

Though probably not serious I deleted the browser exception, logged in again (with http) and did the restore then without getting the warning.
But login now fails both with browser-https and with normal http. Deleted cookies tried it often, different browser…

“Lost your password” would probably work, I guess, or may be changing the PW via phpMyAdmin, but I’d like to know the reason of the issue, if possible, because of some future changes.

Hi Bryle,
unlike backup logfiles, it seems not very comprehensive. I just changed the name of table prefix and domain, so it should be safe too.

0000.004 () Opened log file at time: Sun, 29 Jul 2018 17:19:11 +0000 on https://www.domain.de
0000.004 () UpdraftPlus WordPress backup plugin (https://updraftplus.com): 1.14.11 WP: 4.7.11 PHP: 7.0.24 (cgi-fcgi, Linux zaphod.ispgateway.de 3.14.79-grsec-pvops-xen-x64 #1 SMP Mon May 22 13:12:26 CEST 2017 x86_64) MySQL: 5.6.19 WPLANG: en_US Server: Apache/2.4.29 safe_mode: 0 max_execution_time: 900 memory_limit: 256M (used: 20M | 22M) multisite: N openssl: OpenSSL 1.0.2l 25 May 2017 mcrypt: Y LANG: ZipArchive::addFile: Y
0000.004 () Free space on disk containing Updraft’s temporary directory: 403006.2 MB
0000.005 () Restore job started. Entities to restore: themes, others, db. Restore options: {“updraft_encryptionphrase”:””,”updraft_restorer_wpcore_includewpconfig”:false,”updraft_incremental_restore_point”:-1}
0000.027 () Will not delete any archives after unpacking them, because there was no cloud storage for this backup
0000.029 () Entity: db
0000.029 () restore_backup(backup_file=backup_2018-07-05-0722_Praxis_cf2aecf72e14-db.gz, type=db, info=a:0:{}, last_one=)
0000.029 () Unpacking backup… (backup_2018-07-05-0722_Praxis_cf2aecf72e14-db.gz, 0.4 Mb)
0000.031 () Database successfully unpacked
0000.032 () Restoring the database (on a large site this can take a long time – if it times out (which can happen if your web hosting company has configured your hosting to limit resources) then you should use a different method, such as phpMyAdmin)…
0000.032 () Using direct MySQL access; value of use_mysqli is: 1
0000.041 () Tried to raise max_allowed_packet from 16 MB to 32 MB, but failed (Access denied; you need (at least one of) the SUPER privilege(s) for this operation, b:0;)
0000.041 () Max packet size: 16 MB
0000.041 () Entering maintenance mode
0000.041 () Enabling Maintenance mode…
0000.042 () Backup of: https://www.domain.de
0000.044 () Content URL: https://www.domain.de/wp-content
0000.044 () Uploads URL: https://www.domain.de/wp-content/uploads
0000.044 () Old table prefix: prefix_
0000.044 () Site information: multisite=0
0000.048 () New table prefix: prefix_
0000.050 () Processing table (MyISAM): prefix_options
0000.271 () Restoring prior UD configuration (table: prefix_options; keys: 3)
0000.297 () Processing table (MyISAM): prefix_users
0000.308 () Processing table (MyISAM): prefix_usermeta
0000.321 () Processing table (MyISAM): prefix_commentmeta
0000.331 () Processing table (MyISAM): prefix_comments
0000.342 () Processing table (MyISAM): prefix_links
0000.351 () Processing table (MyISAM): prefix_postmeta
0000.486 () Processing table (MyISAM): prefix_posts
0000.604 () Processing table (MyISAM): prefix_term_relationships
0000.617 () Processing table (MyISAM): prefix_term_taxonomy
0000.625 () Processing table (MyISAM): prefix_termmeta
0000.630 () Processing table (MyISAM): prefix_terms
0000.640 () Processing table (MyISAM): prefix_bt_blocks
0000.650 () Processing table (MyISAM): prefix_bt_layout_meta
0000.660 () Processing table (MyISAM): prefix_bt_snapshots
0000.668 () Processing table (MyISAM): prefix_bt_wrappers
0000.675 () Processing table (MyISAM): prefix_duplicator_packages
0000.679 () Database queries processed: 50 in 0.64 seconds
0000.685 () Processing table (MyISAM): prefix_hw_blocks
0000.698 () Processing table (MyISAM): prefix_hw_layout_meta
0000.707 () Processing table (MyISAM): prefix_hw_snapshots
0000.715 () Processing table (MyISAM): prefix_hw_wrappers
0000.722 () Unlocking database and leaving maintenance mode
0000.722 () Disabling Maintenance mode…
0000.722 () Finished: lines processed: 64 in 0.69 seconds
0000.723 () Cleaning up rubbish…
0000.734 () Entity: themes
0000.734 () restore_backup(backup_file=backup_2018-07-05-0722_Praxis_cf2aecf72e14-themes.zip, type=themes, info=a:2:{s:4:”path”;s:42:”/kunden/auftrag/wpfolder/wp-content/themes”;s:11:”description”;s:6:”Themes”;}, last_one=)
0000.735 () Unpacking backup… (backup_2018-07-05-0722_Praxis_cf2aecf72e14-themes.zip, 6.8 Mb)
0001.345 () Moving old data: filesystem method / updraft_dir is potentially possible
0001.345 () Moving old data: can potentially use wp_filesystem method / -old
0001.345 () Moving old data out of the way…
0003.216 () Top-level entities being moved: headway, bloxtheme, twentyseventeen, index.php
0003.217 () Moving unpacked backup into place…
0004.978 () Top-level entities being moved: headway, bloxtheme, twentyseventeen, index.php
0004.981 () Cleaning up rubbish…
0004.984 () Entity: others
0004.984 () restore_backup(backup_file=backup_2018-07-05-0722_Praxis_cf2aecf72e14-others.zip, type=others, info=a:2:{s:4:”path”;s:35:”/kunden/auftrag/wpfolder/wp-content”;s:11:”description”;s:6:”Others”;}, last_one=1)
0004.985 () Unpacking backup… (backup_2018-07-05-0722_Praxis_cf2aecf72e14-others.zip, 0 Mb)
0004.989 () Cleaning up rubbish…
0005.180 () Restore successful!
0005.180 () Restore successful

Hey Cory,
you’re fast as lightning with answering.

I guess almost everyone has a .htaccess with at least one or two custom edits and it’s important to know, that you have to reconfigure it afterwards.

So, in my case, I can use the shortened “.htaccess” and add my custom codes (301-redirect, deflate ect.) again. OR I activate the original copied one by renaming it from “.htaccess….orig” to “.htaccess”. I have no plugins which edit the .htaccess.

“Hope that answers all your questions!”
Thanks for your efforts. There is only one question left: Is it really necessary to delete all content of the website folder before starting the installer.php? All WP-folders/files and other files like htpasswd, wp-config, robots.txt ect.?

May be it’s just because I’m not a webdesigner, developer or in any other way trained to do these things and because I’m a bit anxious. But as I told you in my last post, even in your recommended videos already existing WP folder/files are not (always?) deleted before starting installer.php.

If yes, you may have some calming words for me :).

Btw, the best thing with Duplicator in my eyes are all the scans and hints which give a high degree of security. Sure, a plugin cannot cover all possible configurations and maybe mistakes of webmasters. Even more your extremely positive reviews are impressive.

Hi Cory,
thanks for your response.

1a) .htaccess
After installing the clone of my live site locally there was only one thing I had to do: the conversion of the old theme to its successor (basically the same theme, different name ect.). This shouldn’t affect my htacces, which has an admin password, a 301-redirect rewrite rule, deflate compression, browser caching and of course the WP standard code.

Let’s say I make now a new duplicator clone locally and install it on back on my live site, without any special actions like excluding it via Dupl.-options. Then I will have finally exactly the same two .htaccess-files in my folder there, like I have now locally?

If yes, then I will have to rename the “orig-copy” to “.htaccess” and delete the shortened one. Because otherwise my shortened “.htaccess” will miss several codes.

Independant from this all, I should do the “resave permalink” in step 4, right?

1b) Before starting the installer.php on my live site the website folder there should be really empty, except Duplicator-installer/archive?

Deleting manually per FTP all WP-Files (htaccess, htpasswd, wp-config, wp-content ect.) makes me a bit trembling… ?? and even in one of your recommended videos Denver COder Timothy Meyers does in NOT: https://www.youtube.com/watch?v=gv5d0xKko_U

2. The webserver allows CREATING new theme-tables by the conversion plugin, but they were NOT FILLED with entries. This is a fact, which shows my phpMyAdmin. Doing it locally both created and filled new tables, no problem here.

The reason is unclear, but theme developer supposes any security measurement of the server, which blocks the inserting of rows. And whatever may cause the blocked insert… I asked myself if it could block Duplicator doing its normal job….

Hi Cory,
I will try.

Thanks.

Marked as resolved.

Hi DNutbourne,
thanks.

Hi DNutbourne!
automatic scheduled backup worked yesterday, though my admin password protection via htaccess is still active and though you said it wouldn’t work, because every PW protection via htaccess would deactivate WP scheduler.

I don’t mention it in order to criticize, but is there an explanation? Will it stay in future?