Search the Community
Showing results for tags 'file permissions'.
Found 3 results
-
After upgrading to PHP 8 I now get errors like this in one of my sites: Unable to load Modules Unable to create directory /home/myusername/public_html/mywebsite/site/assets/cache/FileCompiler/site/modules/JquerySelectize/ ...and trying to clear caches: Fatal Error: Uncaught Error: Class "CacheControlTools" not found in site/modules/ProcessCacheControl/ProcessCacheControl.module:284 Other sites were mostly fine now, including Cache Control, but earlier I've had several other issues with suddenly unreachable folders here and here and here after making PHP and Apache changes via EasyApache. Are these known issues? Does anyone recognize them? How can I fix them? I've tried triple-checking/resetting folder ownership/permissions, but can't find a definitive guide what those settings should be and am probably only making things worse. -
I have added favicon files (.png, .xml, .ico, .svg) into site/templates/images/favicon/ folder. I refer to them in _after.php, <head> tag. Problem is that favicon does not show. When I go to the address of the .png icon, it shows the basic blue icon with question mark = something is wrong. But when I check .svg file, it shows correctly. Browser console and ProcessWire error log don't recognize any issues. All files have chmod 644, and all folders 755. All images added into site through ProcessWire admin are displayed correctly. What could be the caused of this issue?
-
Right now I am not particular proud of myself, because I maybe had the first occurrence of an hacked ProcessWire installation known to mankind. But not because of ProcessWire itself, but of a stupid mistake I have made. Anyways I want to share my case here: Over one and a half year ago I developed a medium sized website with ProcessWire 2.6.1 for a small community. In the process of releasing the site I had troubles with getting the installation to run on the shared hosting webspace. Because the hoster hadn't configured their file permissions correct, I was forced to loosen up the file permissions inside the site/assets-folder. Because I was desperate and wanted the installation to work I ended up setting every file and folder permissions inside the folder assets to CHMOD 777. I wasn't very happy with this solution and now I know how stupid it was, but I didn't knew better and at least the installation was running. This week I wanted to make a small change to the site and noticed something strange: There was a file called sites.php inside the root folder. At this moment it was clear to me, that my installation was hacked. I immediately downloaded the whole infected installation and compared all files with my local clean installation using a diff tool (Kaleidoscope). After comparing I noticed that inside the index.php one line was inserted which included a functions.php inside the site-folder. Also I noticed that inside the site/assets/files-folder there were several php-files uploaded with the same naming convention like the generated images variants (f.e. filename-large.jpg). So what did those scripts do? Luckily not much, that is the reason I haven't noticed this hack for a long time. The database is as far as I can tell not corrupted and the site was still working properly. All those scripts were doing, was generating spam aliases and redirecting to a medical shop site using the http host of my site. Interestingly on my research I have found out, that most of those malicious scripts were intended to infect Drupal and WordPress installations. A few of those files inside site/assets/files are explicitly targeting WordPress specific functions. If you are interested I can share those scripts for further investigation. But I am not sure if uploading those scripts directly to this board is against the board rules, so if I should upload them to a external service, I am willing to do so. Meanwhile I am confident to have cleaned the site from almost all malicious scripts (I will investigate further) and I am still removing all spam search results from Google using the search console. Also I am in contact with the hoster and try to sort things out, even if it means switching the hoster (which I would prefer). Please don't be to harsh with me. I know I have made a stupid mistake and learned my lesson the hard way, but I wanted to share this story anyway to prevent others from making the same mistake. So always make sure to secure your file permissions! Regards, Andreas
