unable to run "update.php" - drupal-7

I had a Drupal website in drupal 6.x When i wanted to upgrade it to 7.x, the custom theme i was using was absolutely outdated, so i imported my Zen subtheme from another website. For doing that, i just copied the folders "zen" and "mytheme" from the other installation to this one. Then i selected "mytheme" as the current theme and changed some little things to adapt it.
The fact is now i'm experiencing the following problems:
I can't auto-update nothing. It downloads the files but then it stacks (and leaves the site in Maintenance Mode).
I can't run update.php. I can go on until i reach the "Run updates" step, which shows a blank screen. This is the main issue, i think, as it evidences -in my oppinion- a problem of communication between the site and the database.
In the Webform module i can't select "File" as a Field Type. This one is not that important, but it may be relevant for someone who knows more than me.
Edit:
Recently i migrated from a Shared to a VPS server. When i migrated, the subdomain in which i was experiencing the issue threw an incompatibility related to the lenght of the password of the database. I changed the password and it started to work again. This may help somebody for helping me. Thanks!

Related

2sxc Content-Type Import Fails with Languages Error

I have a 2sxc App that was written about 3 years ago and was last modified using 2sxc 9.43.2 LTS on DNN v8+. I restored the old DNN site and got everything working locally. I wanted to import this app in to a modern DNN v9.10+. I chose 2sxc v13.12.1 LTS. I installed that on the new, clean install of DNN 9.10.02 and then upgraded 2sxc on the old DNN v8 site to v13.12.1. Tested the app, still working! I figured if 2sxc was the same on both instances I'd have a pretty good chance of the import/export working.
First I tried exporting the whole app. That fails and I can't find any useful errors logged anywhere. So I switched and decided I would just export the content-types and rebuild the app manually since it only had 3 or 4 views, 3 content-types, and 1 query.
But exporting any of the content-types fails on import. See screen-clip below. I think I understand the error, but I am not clear as to what I need to do to fix this. Both the old site and the new site only have the DNN default, US English. Neither ever had another language added, there doesn't appear to be any differences in the DNN settings for this, I compared them side by side.
So what is the fix? Is there something I can change in 2sxc or the App in the old or new site to get the export/import to align? Can I just add the needed language to the Zone? If yes, where and how do I do that?
Can you explain what the error means, "entity has 1 zone has 0 used-list: 'en-us'"?
If I just need to add 'en-us' in the Zone, what does that mean or how do I do it?
screen clip:
It means that the json which is to be imported does report a language - en-us. I'm not sure why - maybe the source did activate english at some time.
You should be able to get this going by exporting a content type from the target system and comparing the json with the one you want to import, and probably manually patch it.

Issue with 2sxc remove action

I have just started a new site where I am using 2sxc version 11.11.4 (started with 11.7.3 and upgraded to see if that would fix it). I have the data and views set up just like I have done on another site using version 10.25.2. On the newer version though, I'm unable to use the remove button/action. I did some searching and found a few references to adding lines to the web config file (https://github.com/2sic/2sxc/issues/1654, https://github.com/2sic/2sxc/issues/2205). I tried this and it worked great.
So, my question: will a fix be implemented for this or will we have to add these lines of code to the web config file on any site we use 2sxc on?
Also, could these lines of code affect any other DNN features, other modules, etc.?
I think you are talking about my solution here
https://github.com/2sic/2sxc/issues/2205#issuecomment-705647892
This is specific to a server where the WebDAV features have been added/enabled in Windows. I do not think its an issue that can or will be fixed in 2sxc.
I do know that it is safe to add those two items in web.config. All its doing is telling ASP.NET to NOT make WebDAV available in this application's (DNN's) context. I am not aware of any DNN feature or modules that need or use WebDAV. Its just something handed down from the server because its installed and its causing a weird change in behavior that makes the DELETE (and other) command types get ignored (IMHO, presumably because they are handled before they get to DNN).

pgAdmin 4 version 3.0 Query tool Initializing error on opening any query editor in browser

When clicking on a table and then selecting 'Query tool' results in an error.
I also couldn't find the log folder of pgAdmin.
It doesn't matter where I open the editor it always shows this editor.
I have re-installed multiple times, version: 10.4 and 9.6.9 search on stackoverflow for a lot of different solutions like resetting the layout or changing the local ip from 127.0.0.1 to localhost.
My teacher also never saw this before, so he couldn't help me either.
If anyone has had this problem before I would really know what the solution is. Apart from re-installing windows.
EDIT:
I have re-installed windows... And stept away from pgAdmin now. I use another tool (HeidiSQL).
This problem has plagued me for months. Finally, I stumbled across a fix that worked for me. I hope it helps you.
In the Internet Explorer browser that is running pgAdmin4 I turned off SmartScreen Filter under Settings -> Safety, and this instantly fixed the problem.

Drupal 7.17 - Do I have to remove these files after installation?

A site I'm currently managing has Drupal 7.17 on it. I'm noticing the following files in the root of the website:
install.php
CHANGELOG.txt
INSTALL.txt
INSTALL.mysql.txt
INSTALL.pgsql.txt
LICENSE.txt
MAINTAINERS.txt
UPGRADE.txt
Researching this, tells me that as of Drupal 7.16, they fixed a security issue that would allow arbitrary code to run in install.php that would allow the re-installation of Drupal that someone could run. But basically, I am wondering if any of these files (if left in the server root) could cause problems in Drupal 7.17? Do I have to remove these files for security reasons? Or is this no longer a security risk whatsoever in Drupal 7.17?
I understand that we shouldn't remove the upgrade.php file, but just curious on the rest of these files.
Thanks, and this is probably a dumb question, but just felt the need to ask anyways. Usually I remove these files when I install software on websites, but not sure how Drupal uses and/or misuses these files.
Based on the document “Finalize the upgrade” (which applies to both upgrades and installations) from the Drupal handbook:
The last step in an upgrade is to delete or move the following files from your site:
install.php
CHANGELOG.txt
INSTALL.txt
INSTALL.mysql.txt
INSTALL.pgsql.txt
INSTALL.sqlite.txt
LICENSE.txt
MAINTAINERS.txt
UPGRADE.txt
Just to make that clear: the only PHP file to delete is "install.php" (i.e. be sure to leave "upgrade.php" and all other PHP files). And when you delete the TXT files, be sure to keep "robots.txt" since it is used by search engines.
You shouldn't delete any files. If you really wanted to, you could delete various txt files. A better solution if you are afraid of security is to not let the files be accessed through the web server. Drupal only use the index.php file for serving content.
I would love to hear an update and more recent thoughts on this question, and here is why.....
I was just working with a newly updated Drupal site to Drupal 8.9.20 running the Open Social distribution as a logged-in user with no admin privileges. This is my ACTIVE PRODUCTION site!
I deleted a node (News Article) I was trying to embed from a website that refuses to connect on some of their metadata ie: image #1, and after submitting on the delete link, the browser switched to install.php, which as you know sites in the document root.
I was of course shocked to see this and after considering the even innocent response a user might get that lead them to reinstall THEIR App, this could be very dangerous, of course.
So, since the last reply on this references Drupal versions from 2014, I was
just wondering your thoughts in this day and age on what are the latest recommendations!
Thanks

setting up asp application on hosting provider changing

i have never worked on windows iis, asp and mssql but now i am forced to do so.
the plot:
i have an asp mvc application (the exact folder tree copied from the old disabled server) and an mssql backup file (.bak). I have managed to restore the database and i have copied my application folder to httpdocs. BUT still...when i try to access the server it pops lots of errors. i know, lack of knowledge and app setup.
my question, in what order should i start setting up my app (what files, what settings..etc for a complete windows noob); i have no start point, i'm confused, put me on the track please. Any advice will be appreciated, any reference.
Keep in mind that i have advanced knowledge in apache server, php, mysql, html, css, javascript BUT ABSOLUTE ZERO in IIS,mssql,asp :D
PS: it's kind of urgent! and i have to learn as i go.
What kind of errors are you getting?
is an code error? or what?
in my experience, when you get a new windows hosting, or server, sometimes you need to activate .asp pages, since it reads only aspx by default, also, to see the code line errors you need to configure that, because normaly the errors are hidden.
to show errors on a server, you go to control panel, administrative tools, IIS, and then somewhere is the option to show errors on browser.
If you are in a hosting with plesk there is also an option to enable .asp pages and to show errors on browser.

Resources