This is a problem because…
Context: My end goal with this was to self host my own WordPress website in a docker container on my home server, and have been following tutorials to do just that. There were a bunch of other steps I took that contributed to getting me into this mess with wordpress like setting up the domain I purchased in cloud flare and then in Nginx proxy manager that I was also hosting, but they shouldn’t have affected this other than leading me to make these mistakes when I didn’t get the expected result after trying to visit my domain.
I’d already gotten wordpress running correctly in docker, visited the webGui and set up my account, and saw that it had created many files in my wordpress folder on my server. The first issue I ran into was that, in confusion as to what I was doing wrong after setting up my domain in Nginx and it still not giving me the expected congratulations screen when visiting my domain and instead loaded infinitely, I was throwing everything at the wall to see if anything would stick. I decided to go into the settings of wordpress and change the Site URL and other site setting to https://[My domain name], changing it from my home servers address and port because I thought it would make sense to make something good happen. This caused the site to become completely inaccessible to me, making me panic a bit, and searched some of the files in WordPress for any ctrl+f match to my domain name, but couldn’t find anything. So instead of searching for and following steps to resolve this apparently and understandably common issue, I thought I could, and that it’d be a good idea, for me to just delete the files and start over again, right? Well, thats what I did by SSH’ing into my home server, navigating to the path that the wordpress files were in, and doing #rm path/wordpress/*. Sure enough, it deleted everything inside of the wordpress directory, so I then deleted the stack in portainer, deleted the images, and re-ran the stack. Portainer showed both wordpress_wordpress and wordpress_db going back up and running again, and the logs in each seemed fine, but WordPress became completely inaccessible to me then. I’ve sinced tried what I think has been everything in editing the stack. I changed the volume that the wordpress files are stored, tried changing the db volume from /var/lib/mysql to mysql1, changed db names, usernames, passwords, everything, and nothing seems to be working. I’ve searched the 2 volumes for db and wordpress for hidden files anywhere with ls -a and can’t find anything. No matter what I try to change and reset, every time I try to run the stack again and visit the WebGUI address and port, I’m just met with an ‘Error establishing a database connection’ screen. I’m not sure if the full story as to how I got to this point was entirely necessary but this is the first time I’ve run into issues with this kind of stuff so bad that I couldn’t solve it for multiple days, have no idea part of what I’m doing and need to do, and really need some help, thanks.
TLDR: I get ‘Error establishing a database connection after deleting everything in my wordpress volume with #rm path/wordpress/* and trying to restart, and don’t know how to fix it :/
]]>I run a Full Scan every morning. I have found through testing that the scan detects the name of newly added files and modified files. But does not list the name of deleted files. It does reduce the total file count at the head of the scan report to reflect the fact that a file or files have been deleted – but does not list the file name.
Is this possible in a future release ?
Thanks,
Keith.
please help
]]>I lost the files through ignoring the wordfence warning if I was sure I wanted to delete all the possibly hacked files.
This is an error that appears when you visit the site, I am currently using css to cover the error up, but would like a more permanent solution. Please help
Warning: include_once(/homepages/7/d436087486/htdocs/clickandbuilds/Otmag//wp-includes/init.php): failed to open stream: No such file or directory in /homepages/7/d436087486/htdocs/clickandbuilds/Otmag/wp-config.php on line 93
Warning: include_once(): Failed opening ‘/homepages/7/d436087486/htdocs/clickandbuilds/Otmag//wp-includes/init.php’ for inclusion (include_path=’.:/usr/lib/php7.0′) in /homepages/7/d436087486/htdocs/clickandbuilds/Otmag/wp-config.php on line 93
]]>I manage a website that is a job board for various nonprofits. Our website was built by a third-party developer before I started with the organization. The website uses the Formidable Forms plugin, as well as the Formidable Forms Pro, Formidable Bootstrap, and Formidable Bootstrap Modal extensions. Unfortunately, I can’t login to your Formidable Forms Pro website to submit a ticket, because I have no clue who purchased the plugin. Most likely, it was purchased by the developer who built our site.
At any rate, we ran across a pretty significant issue. Our website uses your plugin to capture job applications that are submitted. For the past two years, our admin has been logging into the WordPress dashboard, navigating in the dashboard to “Forms” => “Entries”, then filtering to see only the entries from the application form. She then downloads a .csv file of those application form entrees, saves this downloaded file to a folder, and deletes the entries from the WordPress database.
The entire time that our admin has been going through the above process, we were under the impression that these entries and any associated files were being deleted. We assumed this because we checked the setting on the upload field that says, “permanently delete old files when replaced or when the entry is deleted.” Because we delete the entries every month, we assumed that the files associated with those entries were also being deleted.
This week, we discovered that the files associated with those entries were not being deleted. The thing is, our application form lets applicants upload their cover letters and resumes. While most of the form info is stored by your plugin in the WordPress database, and is later deleted by our admin, your plugin stores the uploaded resumes and cover letters in the “uploads” folder of our website files. This means that anyone who knows the file path and file name can access these files, and someone with a sophisticated enough knowledge of servers can locate them through other methods. This week, we learned that we actually had two years of old resumes and cover letters in our uploads folder. We’ve since deleted them, but that doesn’t stop new files from hitting that folder with every upload.
So, my question is twofold:
1) Our assumption was that when you go to the settings for the upload field and check the setting that says, “permanently delete old files when replaced or when the entry is deleted,” that any files associated with a particular entry – including those pdf and image files that get uploaded to the “uploads” folder – will be deleted. Is this not the case? If not, what do you mean by, “permanently delete old files when replaced or when the entry is deleted?”
2) Assuming we’re correct that these files should be deleted when we delete the associated entry, do you have any plans to fix this issue?
]]>Upon deleting the Beta plugin, it had also deleted my entire directory of paid listings, which was just over 500 business profiles. I reached out to my web provider to see if they could restore the listings from backup. They have restored the site to the previous week, but none of the listings have restored!! I am unsure how to resolve this issue and was wondering if the support team could help? I have sent several emails but no one has got back to me yet?
]]>I have had an attack on 9th of February, the hacker managed to overwrite a blog post but after cleaning the site and deleting this, we found out that 4 more posts are lost. So the options to solve this issue are:
1) restoring the entire BACKUP from HostGator before the attack this would bring back the WP 4.7.1. (vulnerable version) of the site with old passwords too.
2) Restore the single 4 posts >>>>how can I do that? Would it be possible to extract these 4 posts from the database of the plugin or from HostGator alone?
3) Restore them manually one by one by using the old permalinks.
Can you please help me in which direction is better to go to avoid to endanger the site again and with the most sensible solution.
Thanks
Michela