I installed the Shopware 5.4.6 community shop.
I now wanted to make changes in the basic settings what is answered with "Basic settings will be loaded" (BTW i use german version so i got "Grundeinstellungen wird geladen").
All other points can be displayed without problems.
PHP Version 7.0.31, Linux 3.16.0-6-amd64, Apache, Shopware 5.4.6
backend UI shows no errors in Shopware logs
backend UI shows shows nothing in the system log.
Resolved / Done / Solved / Workaround:
Tried different things. Also read the apache error logs. did not help.
How I got it work:
have uploaded and installed a fresh shop in a subfolder of the shop. this time the basic settings were accessible.
So I just wanted to give it a try again (in the home folder)
So i deleted (all inside the shop home) and uploaded again. istalled. and even then the basic settings were accessible.
I noticed:
during these installations the assigned rights for individual files were no longer required / required / remindet during the installation.
may because I had recursively set writing permissions in the shop folder (sometime yesterday when trying around).
I have not tested now if the error occurs again, if I do not give this home folder at the beginning writing permissions recursivly for php. uploaud just takes too long at this lame server. it took a whole hour to empty the content folder (FTP access).
Too bad the shopware 5.4.6 could had no error messages. Maybe too rare a case.
Related
I seem to have an issue with the file preview in the documents which throws me a xyz and logs me out. See image here
It doesn't matter what I change including removing the / from the root and site address in config php file i just cant get it to work.
Ive followed its4you install instructions with the correct chown and owner permissions etc for the full install. I then decided to set a brand new instance up on a new server and it is the same. So i reconfigured a different server on amazon web services running ubuntu... exactly the same issue.
I have a similar issue when i installed pdfmaker and tried to browse server in the editor (fck possibly), it would show me blank thumb nails, if i click one then save it would close the session and log me out.
I have several versions of 7.1 running on the same servers without issue.
Any ideas?
Found the answer to this. Whilst browser through two comparative server setups I noticed "Varnish" was enabled on the new instance running VTiger 7.3. I turned this off and hey presto, issue resolved!
Firstly I know how to deploy and work with files, I don't need answers saying 'redeploy static content' or 'clean cache' - experience from the research.
We having an issue on our development server. We have tested it with multiple projects, versions vary from 2.1.5 to the 2.2.3 open source.
After steps below we are receiving random 400 errors on some files (1-10 files). All those files are .js.
FUN PART:
After trying to get that file again (open in new tab) - everything is working fine, file is there, nothing bad.
After trying hard refresh again - again errors, but on other files.
After multiple soft refreshes (F5) - it looks good again.
Deployment mode - Developer
Steps to reproduce
Install Magento without Sample date (tested with 2.2.3) - nothing configured.
Set deployment mode Developer
Deploy static content or just clean /pub/static/
Chrome/Firefox - Inspector->Network tab->Disable cache (CHECKED)
Clear site data on the browser.
Create a product - for testing.
Go to the website and then to the product (no errors even after hard refresh).
Add product to the cart. (no errors even after hard refresh).
Go for example to the category. (errors even after hard refresh).
After clearing site data - everything looks fine again.
We have reproduced this on multiple pc's / webbrowsers.
Server info:
PHP: 7.1.16
APACHE: 2.4.33
DirectAdmin 1.52.0
Debian: 8
Any suggestion what to do or what to check/change will be useful (except a stupid ones, no one likes those)
P.S. I was not sure if I should post it here or magento.stackexchange.com
Or if I can post on both websites at the same time.
Good morning all
After all we have found an issue. It was an apache module : mod_ruid2
After it was disabled - no more random 400 errors has appeared.
I hope this anwer will help someone even if this is an uncommon issue.
To turn the module off, you need to do the following steps in the command line:
cd /usr/local/directadmin/custombuild
./build set mod_ruid2 no
./build apache
I have a fresh wordpress 4.0 install on my server for a specific domain and when I make changes to any of the theme files it won't show up in the browser for a few reloads. I just add "asdf" to the theme file to test changes. I can refresh 20 times but no changes show up until like 20 seconds later.
What I have tried:
Turned off firefox's cache.
Turned off wordpress cache.
Tested other domains on my server with wordpress and they work properly.
Installed wordpress with "server installer apps"(3 times) and also with manual installation.
I refresh with ctrl+f5
Tried with firefox and with chrome, same results.
Its a fresh install so no plugins, no settings changes. There is no caching and my other domains work properly. No errors show up in the console.
I have no idea what the problem could be. My server company, mediatemple, said it could be my ISP, but other domains on my site work properly from the same computer/network. For some reason the problem is specific to this domain and the problem persists through all the themes.
I don't know what to do next. Any suggestions would be greatly appreciated. :)
Update:
Have tried manual install of wordpress 3.9 and that does nothing.
I added a new folder to the root and in that folder I added a file called index.html to test if this file, which is unaffected by wordpress, would show instant changes and IT DOES. So the problem seems to be based within wordpress and specific to this domain.
I spoke to Mediatemple for the 3rd time now and this guy was much more helpful and he actually solved the problem.
When you add a domain to mediatemple it automatically sets the PHP version to "FastCGI", which normally is fine, but it caused problems specifically on this one domain's wordpress install for unknown reasons. So he switched the PHP version to "CGI (Stable)" and that fixed every problem.
I hope this will be helpful to someone in the future. :]
I have just moved a silverstripe install to a new joyent smartos server. Not being familiar with Linux, this was still relatively easy.
I am new to silverstripe as well, but the team here has developed on it for years.
I have the site up and running on the new server, but have not pointed the domain to it until we can thoroughly test it. So I am accessing it from it's ip address. The site displays fine and the sub pages work as well. When I navigate to the '/admin' page, I see a silverstripe page that states the page cannot be found (not an Apache 404). I copied over the .htaccess and the _config.php from the old server, so there should be no issues.
I have done a /dev/build with no errors and I can log in through the security page, but I just cannot get the /admin to come up. I am lost after spending the whole morning surfing google to find the answer. Any help would be greatly appreciated.
UPDATE:: I installed a fresh version of silverstripe into a subdirectory on the same server. Works perfectly, so that rules out any PHP issues.
I have also tried /index.php/admin with no luck.
Thanks,
Ben
I was having this problem as well. None of the solutions I found online worked for me, but I managed to figure it out.
I had apache running as a non-standard user, and the problem turned out to be that the webserver was unable to save session data for the logins.
The solution in my case was to chown root.myuser /var/lib/php/session. Once done, the admin page loaded fine.
If /admin is not loading at all and there is no 404 error, there is a high chance of a PHP error. And that should be logged in the webserver's log file. This will depend on your operating system and probably on the Joyent environment (not familiar with that breed of cloud computing). On Debian, Ubuntu, and some more it's /var/log/apache2/error.log (assuming you're using Apache).
If I had to guess, I'd say the permissions of assets/_combinedfiles/ are bad. The webserver tries to create some combined JS and CSS files there (specifically leftandmain.js and cmsmain.js) and if it fails, you might get the dreaded white page of death in /admin.
I have a weird case here....
I'm making a simple magento module right now. Some kind of script injection module (similar to google analytics module). I've built the admin config for that module (which is defined from system.xml)
as seen on the image. This module works very well on my localhost. But it's getting weird on the live server. The modules looks like it doesn't enabled at all although I have totally make sure it's all already enabled. Both via magento admin area and also via app/etc/modules. That admin config area never appear on live server's magento installation.
does anybody know what's the issue with this problem?
or at least tell me how and where should I debug it? I've been digging it to magento core code but getting stuck on getSingleton() function somewhere around magento core code. I don't understand that way-too-MVC stuff :p
I would be very glad if someone could explain and guide me on this
thanks :)
The most common problems are associated with case sensitivity. If you have Windows hosting, then the error in the uppercase/lowercase characters is not visible and it works. But as soon as it gets to linux hosting, the module will not work.
Check the paths in the settings and folders/files - so that they match.
Usually there are three things:
typos in xml files (validate them with validator)
cache is not cleared after installation (clear cache)
ACL rules are not reinitiated (re-save admin roles)
If you adjust the layout/add your own layout in the backoffice of magento, it's best to clear the cache (remove everything in the var/cache/ folder) and to logout and re-login.
Thumb rules while deploying magento custom module on the live server-
Deploy your custom module
Flush your all magento cache or at-least refresh them
[System->Cache Management]
If you have enabled compilation re-run the compilation or disable compilation until the testing is done.
[System-Tools->Compilation]