I got a strange situation.
I'm using VQMOD with Opencart and everything worked alright until I uploaded all the code to a secure ssl hosting.
VQMOD still works and is making all the cache files in vqcache. In checked.cache file however not all the modded files are listed. Is this normal?
logs, vqcache, checked.cache, mods.cache, system/cache and logs have permissions set to 777
It seems that VQMOD is not using all the plugins (using the normal files instead of the vqcache file). I have no errors.
Can someone help me with this?
Checklist of things you need to do
Delete the files /vqmod/mods.cache and /vqmod/checked.cache
Remove all cache files from the /vqmod/vqcache/ directory
Make sure your write permissions are valid on /vqmod/, /vqmod/vqcache/ and /vqmod/logs/
Make sure the files in /vqmod/xml/ are readable by the web server user
Make sure the file /vqmod/xml/vqmod_opencart.xml is present
Go to http://yoursite.com/vqmod/install/ to make sure everything is installed correctly
Related
I want users to upload their themes containing .css, .js files to my server in zip format, Once they will upload the application will unzip it and the user will be able to see the theme at mysite.com/themes/user/. I want to know what security issues can occur if I allow user to upload .css and js files to my server. Can the malicious code redirect the site or do DOS service attack or change the dynamic aspects on my site. Scanning the files for malicious code before unzipping seems impractical. What safeguards should I take.
First and foremost, don't unzip them into a public "temp" folder while you're doing whatever else you're going to do with them.
There's no telling what that ZIP file will actually contain.
There's no telling what those JS files will try to do to your site.
You should read what Samy did to MySpace before you implement this functionality. (A breakdown of the attack.)
I am doing a website(Joomla) and I am using admiror gallery. Everything is working fine while I was working in the localhost but now that I migrated it to a live server, I am having problems in uploading images in the gallery.
The first is when I create a new folder to contain my new images. When I create it and try to upload a zip file, it's taking forever to load only to find out that it's not even uploading at all. When I looked into it, the reason is when a new folder is created, the permission is 755 by default, thus, making changes on the folder is not allowed. I need to change the file permission to 777 and now I am able to upload my images but there is another problem that occurs. The thumbnails in the backend are showing broken images. This is because the 'thumbs' directory in home/administrator/components/com_admirorgallery/assets/thumbs/ is again set to 755. I tried to change it to 777 and reupload the images again. The images gets uploaded but the problem with the thumbnails is still there. I checked again the folder and the permission is reverted back to 755.
Is there something I can do with this? Any suggestion is appreciated. Thanks in advance.
You should check the files and folder owner, not only permission.
PHP user (Joomla) is the creator of thumb folder, thus it should be able to create files in that directory. Also, it is not safe to have 777 on live site.
Shambhala made a suggestion that should help. Also you should use AkeebaBackup when migrating from local to live server, I never had problems with it.
Hy,
I am really new to Pimcore (I'm a joomla guy) and my friend asked me if I could help him transfer a page based on Pimcore to another server. I made a sql dump and copied all the files from the server to my hd and after that on the new server, imported the sql database, changed the username in the db and copied all the files back on the server. Also I made the correct changes for the db in the system.xml file in the config folder. But now all I get is a blank screen but the backend works partially (I can't see the files and the page). I would really appreciate some help!
Thanks in advance
Several things could go wrong, but start with checking:
MySQL user has access to the imported views. This is quite a common issue when importing views between servers,
Apache Linux user has read/write access to the whole website/var folder, access to /var/config is not enough. Pimcore writes cache files to website/var/cache for example.
You are missing mod_rewrite in apache, or your vhost does not allow override.
Can anyone help with this strange problem.
I have just installed CF10 developer on Win7 which is using IIS7.5.
Installation went smooth, and can browse .cfm files no problem and connect to datasources no problem .. BUT: even though I can browse all my local cf sites, none of the sites will display images or styles for external .CSS files.
So, I get the site, content from the database, and all the functionality of cfm files being parsed OK, but no styles and no images.
If I browse directly (pasting the filepath in the browser) to one of the images I get a 404 error - file not found - even though the .gif file does indeed exist in the directory.
So, basically, I can run CFM files, and browse a local site built in coldfusion, but none of the images or externally referenced css files will be "found" by the browser/IIS.
Can anyone help?
Thanks in advance if someone can..
Sounds like an issue with those mimetypes, please see the following for information on installing the static content role to IIS and enabling those mimetypes to be served.
No Mime Types Option in IIS 7
Be sure to enable static content in IIS 7.
Had two occurrences of this problem lately.
See here:
http://weblogs.asp.net/anasghanem/archive/2008/05/23/don-t-forget-to-check-quot-static-content-service-quot-in-iis7-installation.aspx
Try restarting the IIS server. Close all browsers and restart.
You need to determine if it is a CF issue or an IIS issue. Try the following:
Check to see if this is an issue with images not being served vs broken paths to the images. There may be CFML code that is creating links to invalid locations.
If the locations are valid then it would be an issue with IIS not server image files.
Also check to see if there is a similar issue with JPEG and PNG files. If JPEGs and PNGs show up, this suggests an IIS issue.
Also try creating a simple HTML page that has an image on it. If it has an image on it, this suggests a CF issue
anytime a user logs into our Wiki they get the following error: "This Wiki uses cookies to log in users. You have cookies disabled. Please enable them and try again." Even though the error displays, the user is actually logged in and can make edits as normal. If the user doesn't look closely they can't tell they are logged in and it's causing confusion I would be glad if anyone gives me a hint
Wikimedia's advice is Check to make sure PHP's directory for storing session data is writable. This directory can be found in the php.ini file under the session.save_path setting. Errors in this php.ini setting can also cause other problems.
... (and) make sure the Internet Guest Account (eg. IUSR_FOOBAR, nobody, or apache) has write permissions to the folder listed in the session.save_path variable of the php.ini file.
Source.
If you are using a hosting site you need to edit your php scripting configuration (php.ini). The page should have information on your web document root. If there is already a "tmp" folder created then use it. If there is not a tmp folder in your current set up create one that is NOT browseable by users and tell the php.ini file the location as directed above.
For future reference... We just had a similar problem on Appropedia (same error, but couldn't log in at all). It turned out the temp directory was full. Cleared the temp directory, problem solved.
It turned out the temp directory was full
In my case it was because the entire partition was full, needed more space.
Problem I just had was due to default install of our PHP using C:\windows\temp as a base folder for PHP session and other data.
Of course, once someone empties out the temp folder because its full of junk .... the sub-folders for PHP information go with it too :\
If you are using NGINX + PHP-FPM the previous answers will likely not be of any assistance.
From the command line, run:
php-fpm -i|grep --color cookie_path
See what your cookie_path is, then stat the folder and ensure your php-fpm user has write access to it.
To resolve this issue using Nginx and Php-Fpm, I had to change my cookie_path from it's default of / (seriously, why would this be a default?) to /tmp.
After restarting nginx and php-fpm, it works perfectly.