A very annoying just surfaced. I did some database tweaking, migrated it and manually imported the user table together with some other tables.
Suddenly the home page of my laravel spark won't display properly. It automatically goes to the settings#/subscription page.
The routes are still intact but are the HomeController is not used at all. I've cleared all caches but still the same. No errors in the log.
And even more annoying as I just found out, it only affects existing users that I imported. New users are not affected. So it definitely has something to do with the MySQL import.
I already compared the users values of a new user and an old one and tried to mimick the new one as much as possible. Doesn't work.
Anyone have an idea how to solve this?
It's been a while so you probably got to the bottom of this, but I just ran into the same issue.
In my case, I installed Spark without the team flag and signed up. Later, I added the necessary code to add teams back in without migrating and seeding. In a few places in my code I'm running the teamSubscribed middleware, and that was the crux of my problem. The redirect started looking at the team subscription status instead of the user subscription status.
Since I didn't sign up as a team, those fields were null, and it redirected pages with the middleware.
For others that come across this:
Search your codebase for the middleware (likely either in a constructor or your routes).
Double check your database for the corresponding user or team active trial status.
Related
Problem: Creating a new storeview does not seem to 'connect' it to the website view, and thus it doesn't inherit its configuration. Also see screenshots below to make things more clear.
Additional Information
Between the last storeview we created, and the new one (Test), no real changes were made to the codebase. The shop has been running on version 2.2 ever since and no new extensions were installed.
I've tried to verify several things, such as checking whether the store was correctly linked to the website (in database table "store"). I also came across a bug, that supposedly existed in version 2.1.3 (as seen in https://magento.stackexchange.com/questions/157925/magento-2-1-3-store-view-config-doesnt-inherit-website-config), I have verified that this fix is part of the code.
Saving the website config to hopefully overwrite the store config did not work, nor did flushing the entire cache (including cache on disk). No errors are shown in the logs whenever a new storeview is created or modified.
Below you can see a specific setting (it happens to ALL settings) in website view
And below what it looks like in the "Test" storeview
I'm a bit lost and not sure where to look anymore. Any help would be appreciated.
I've posted this question on magento.stackexchange.com but got no response due to lower traffic there than here... So here it is...
I'm working on a website for a client and right before publishing the
website, I noticed that all the products went out of stock itself. So
I put them all back in stock and everything looked fine, but when I
checked back after a few hours all the products were back out of
stock.
I tried a few times to re-enter the stock quantities, re-index and
clear the cache, but I'm still having this weird issue - everything
looks fine until like 2-3 hours later everything goes out of stock.
Any suggestion what could be causing this issue?
Thanks in advance!
PS. I didn't share the code because I would have to share the code of the entire website...
Any suggestion what could be causing this issue?
Any imaginable 3rd party application or module that has access to cataloginventory model or its tables in database.
Suggestion how to debug this:
put this snippet into inventory observer
app/code/core/Mage/CatalogInventory/Model/Observer.php
somewhere at the begin of saveInventoryData method. (Or create local module and observe a save event)
Mage::log(Varien_Debug::backtrace(true, true), null, 'inventory.log');
after you reproduce the behaviour just check the log file under <doc root>/var/log/inventory.log
I have modified the users component of Joomla, specifically the file components/com_users/controllers/profile.php and included some custom templates in components/com_users/views/profile/tmpl
It is mostly some forms which I am submitting and then redirecting to specific pages for further actions.
Example scenario :
Above option is accessible to user right after login. I have put it on the profile page by modifying default profile template.
So when someone enters a name, and presses search, then this form is submitted through form
action="<?php echo JRoute::_('index.php?option=com_users&task=profile.selectSendMessage'); ?>"
This in turn calls the function named selectSendMessage which is placed in profile.php file. The function looks like :
As you can see the function redirects to
index.php?option=com_users&view=profile&layout=sendMessage
I have placed sendMessage.php template in com_users/views/profile/tmpl
Everything works fine on localhost which I have set up on MAMP in MacOS
I moved the website to a live server a few days ago. I have followed all proper steps to migrate website and database from localhost to live server. Still any of the custom templates I have put in are never reached.
The strange thin is that Edit User Profile which is redirected to from the same profile.php file from a function edit(), with template in the same location as I have put in edit.php in views/profile/tmpl works as expected.
I am using 1and1 shared hosting plan 1&1 Unlimited for hosting the website.
I have been trying to fix this for quite some time now, but cannot understand the problem. I have tried reinstalling the website several times, tried installing from web apps from 1&1 control panel and modifying it, but no success.
Any tips and insights are welcome. Thank you.
It turns out that 1and1.com hosting somehow doesn't support layout names with a capital letter in it. I changed all layout names to lower case alphabets and everything worked fine like it should.
If someone faces the same issue, this is worth a try. It was particularly hard to debug since you will never suspect that could be a problem. I accidentally stumbled on the solution while playing around.
Thanks.
I have two projects of sugarcrm installed on my local server, nothing wrong with that.
Now I start my first project i.e. sugarcrm in the browser, login with the credentials, and after that when I opened the second project i.e. demo_sugarcrm in the browser and login, my sugarcrm session is expired.
And same with the demo_sugarcrm also. Its session expired when I login to the sugarcrm
What is going on here, I have totally different database of both. they dont share anything except that both are on local sever.
I think adjusting unique_key is supposed to fix this, but as an alternative you could modify /etc/hosts such that 'sugarcrm' and 'demo_sugarcrm' hostnames both reference 127.0.0.1. Then you could visit http://sugarcrm and http://demo_sugarcrm. I'm sure any shared cookie mayhem would go away at that point since the browser would consider these to be distinct sites.
I believe that if you edit config.php and change the unique_key variable to be different between the two instances then you shouldn't get kicked out anymore.
I have migrated a Magento site to another server (the same server the database was already hosted on) and I am no longer able to log in or add items to my cart. I have found a few others who have posted about this type of problem but nothing seems to work for me. I have disabled all caching, etc. Ensured that sessions work. Increased the session lifetime. No errors are being logged anywhere. If I enter wrong credentials I get an error. But if I enter the correct information it just keeps returning me to the login page. I have opened permissions completely. Nothing makes any difference! So aggravated. Please help!
Found the issue. Well sort of. I think there was a problem with the timezone (the server I moved to was an hour different from the other) but essentially I resolved the problem by increasing the values for two config items in core_config_data:
UPDATE core_config_data SET value=86400 WHERE path='web/cookie/cookie_lifetime';
UPDATE core_config_data SET value=86400 WHERE path='admin/security/session_cookie_lifetime';
The first query fixed the shopping cart problem, the second the admin login problem.
Again I think there is a mitigating factor here as well, but this at least got me over the hump.