I am unable to enter data to fields which I have created in user collection type in strapi.
I wanted to create extra fields in user collection in strapi so I created some extra fields from builder , but when trying to enter data , the newly created fields are not editable .
You can try following ways, and check if any one of them works -
Method 1
there can always be an issue with Strapi server,
I restarted the server manually and it is fixed.
Method 2
your user might not have permission to view that field.
you can change permission of a user by -
step 1 - Login to your strapi cms with Admin account and check if you are able to edit that field(the one with no permission), if so then continue with following steps, else this method wont work for you.
setp 2 - click on settings in left panel , select the user , from the list select the user that you want to change permission with, give read write , and other permissions you want to give.
re-login with your account from which you were facing the problem, it should work now
Method 3
There might be a sync issue with your DB, sometimes your data is not synced with your DB, try deleting the field and re creating it.
I hope one of this solves your issue
After I ran into the issue multiple times myself and couldn't fix it even after re-deploying again (and again...), I found the following worked for me:
In the deployed version, go to Content-Type Builder
Select the content type that contains the field causing problems
Click the Configure the view button
Change the position of an arbitrary field
Click Save
This worked for me and also didn't require a re-deployment of my app.
Related
I splitted the database, and then did some changes directly into backend. and then i tried to open front end, it failed to open and just asking for new/other files to open. what am i missing here ?
I gave up and opened my another backup access file and splitted it in frontend-backend. let say frontend name :DBstore7_fe and backend name:Dbstore7_be. link is ok and i can update data from front end. but i have to keep my old version of backend(Dbstore6_be) in the same folder. if i remove this old backend version, my frontend fails to open.
i tried another thing, i imported back all the tables to the front end, i.e - no more backend/linking. but still it is looking for Dbstore6_be. if this one there ....my database loads otherwise prompting for blank version.
You must run the "External Data", "Manage Linked Tables" wizard whenever you move or modify the backend file.
A web site I have published is generating the error stated below when a valid user submits form content to be stored in the database:
Forbidden
You don't have permission to access /index.php/user/add on this server.
Additionally, a 404 Not Found error was encountered while trying to use an
ErrorDocument to handle the request.
This is a private web site. All users have to log-in. Some users can add content. Using CI sessions there is an added field of edit, with a value of 0 or 1 retrieved from the user's record in the user table, copied to the user_data session array at the time of log-in. The variable $this->session->userdata('edit') is used for if statements in the controller and views. Value of 1, user will see links that will bring up views (forms) to edit or add content.
This is a snippet for how I am using the variable to set menu items:
<?php if ($this->session->userdata('edit') == 1) { ?>
<li>Add</li>
<?php }; ?>
This is the basic structure for the processing of form data. This function is in the controller file user.php:
function add(){
if ($this->session->userdata('logged_in') ){
//runs form validation
if ( $this->form_validation->run() == FALSE ) {
//if false, redisplays the form and data with failed fields highlghted
}//if
if ($this->form_validation->run() == TRUE) {
//processes the data and stores in the database
}//form validation run
} else {
redirect ("user/login");
} //if...else
}//add
Examining the database after one of these Forbidden errors, no data is inserting. A redisplayed form due to validation error(s) is not happening either. These factors lead me to believe this is a server problem more than a CodeIgniter issue. If you look at this link it shows a screen shot of the error received in the browser (either Firefox or Chrome, other browsers not in use yet), it is not the usual CodeIgniter appearance for an error generated from a mistake in CI code.
The add/edit content forms are working well. As stated above, the error occurs at time of form submission. As well, it is only happening on the hosting company's server. I have checked the permissions of user.php and they are 644 like the rest of the files.
What are possible fixes? If it is a server issue, what do I look for or ask my hosting company to look at? If it is a CI sessions issue, in the documentation CodeIgniter states it uses a system different from $_SESSION super global. Is it wise to copy the user data to that array and have the code look up the data from that variable array? Or do I create a distinct array and save the keys there?
Revision and Solution
I retested the connection to the database associated with this project. I could connect. Taking things a next step, I could select records but not insert. I performed those tests with raw, simple statements.
Examining privileges for this user and the database, I discovered that while All Privileges was checked, none of the individual privileges was checked. (See this screen shot.)
I ignored the All Privileges check-box and manually checked each of the other boxes. Conducting small tests like the ones outlined above and then interacting with the form on the site, I am getting results I expect.
Things I don't understand:
How can All Privileges be checked and none of the other check-boxes checked?
I have gone back and tried to check All Privileges and then uncheck the others individually. It's not possible. From interacting with Panelbox on this host often to set-up users and associate them with a database, I know it is not usual for the state I found described above.
Programmatically, since there is only one user and set of privileges associated with a CodeIgniter site, how was the admin for this site able to insert 5 records in the database before a Forbidden error started being returned from the server?
I did not outline it when I first posted this thread, but the Forbidden error did not happen right away with uploading and running the site from the server. Since the admin was able to submit five completed forms perfectly before starting to receive errors, I presumed it was a Sessions problem. This contention was also arrived at because sometimes deleting the cookie and then logging in, I or the admin was able to submit a form and the data was inserted in the database.
Thanks for taking the time to read this.
Test user privileges associated with a database often. Sometimes things change.
I just move my Magento store to my localhost environment for testing use, I also using Git to maintain code, but after I move all the files to my local environment, I can't login my admin page, but I can still see my frontend pages, and the git, the database, seems works well.
When I type a wrong admin/password to my admin page, it still gives me "Invalid password".
But when I enter the right one, it just refresh the page and stay at the login page, nothing happens.
Does anyone has met this problem before? Has any ideas?
Thanks in advance!
Although this question is old, all the above answers did not work for me until I did one additional thing.
Follow the very helpful answers already posted (summary):
Change your base_url to http://127.0.0.1/ for secure and unsecure path.
delete files in var/session and var/cache
alter your Varien.php file accordingly - depending on your version of Magento.
And then:
Finally, use http://127.0.0.1/your/site/folder/name/index.php/admin
It was the lack of the index.php/admin ( instead of using http://127.0.0.1/site/admin ).
I hope this helps someone else.
Recently started using Magento for a project and came across this issue. I was left frustrated by the fact there are at least ten or more different workarounds suggested on the net and it took a bunch of trial and error to find one that did the job. Seemingly some workarounds work for some versions and not for others. No one explained why or how the problem occurs and the most popular solutions involve hacking the code base or using a different url, which shouldn't be necessary.
The cleanest solution I found for Community Edition 1.9.1.1 was editing two config values in the database:
update core_config_data set value = NULL where path = "web/cookie/cookie_path";
update core_config_data set value = 0 where path = "web/cookie/cookie_httponly";
The cookie path is actually NULL by default on a fresh installation but it must either be NULL or empty string.
The behavior arises because some browsers including Chrome have issues creating cookies with a localhost domain, this means that when Magento calls session_start() the session identifier cookie never gets created and as a result information can not be passed from page to page. The login procedure is actually successful but the next request doesn't know about it, hence why you get redirected back to the login screen. There are no errors because Magento doesn't account for this edge case as a possibility.
If you do not provide a domain value when creating a cookie on localhost then the browser has no problem with it. Unfortunately just setting web/cookie/cookie_path to NULL is insufficient, because Magento's configuration class resolves this as an empty string which is enough for a real domain to be set later in the code:
if (isset($cookieParams['domain'])) {
$cookieParams['domain'] = $cookie->getDomain();
}
This method eventually uses the current HTTP host to resolve a real domain for the cookie, and the browser therefore wants nothing to do with it. However if we disable web/cookie/cookie_httponly then Magento will not perform this additional step, $cookieParams['domain'] is unset and no domain gets passed as a session parameter, thus allowing the session cookie to be created and things to function as they should.
Note that any time you modify the database configuration you must delete the contents of /var/cache/ for the changes to be reflected.
If like me you don't want to have to comment out code, or even make configuration changes, then I created an extension which overrides the getDomain() method shown above and returns null if we are on localhost, this should be somewhat more future proof and result in no collateral damage.
http://www.mediafire.com/download/q39p4k95s5tlght/LocalCookie.zip
Try deleting the contents of the cache folder /var/cache. Clear your browser cookies and try. Also, if you have copied down the database from your server, you may need to manually change the base urls (secure and non secure) as well as the cookie domain in the core_config_data table. Do this manually if you need to. e.g. web/unsecure/base_url with production value of http://www.mywebsite.com/ becomes "http://localhost/"
When ever I have had this it's because of this or cache. Ensure the cache folder is ignored in git hub if it's not already.
1.you need remove the cache
rm -rf var/cache/* var/session/*
2.change the domain form core_config_data
update core_config_data set value="http://127.0.0.1/" where path="web/unsecure/base_url";
update core_config_data set value="http://127.0.0.1/" where path="web/secure/base_url";
do these steps :
1: go through: xampp\htdocs\magento\app\code\core\Mage\Core\Model\Session\Abstract**
2: open **Varien.php file
3: make comment line number from 87 to 104 save it and try to login...
Had the same issue, but the fix was changing DB values:
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/unsecure/base_url';
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/secure/base_url';
Then in browser http://127.0.0.1/example/admin
Same problem! I fix my problem after remove/replace static domain in core_config_data Table
web/secure/base_url
web/secure/base_link_url
web/secure/base_skin_url
web/secure/base_media_url
For me, running it on IIS (I know, not officially supported):
Although other suggestions kind of worked I found the best solution was to enter a new A record for me domain like
127.0.0.1 local.example.com
Then in IIS add the binding
local.example.com
to my site and it worked perfectly.
I found there were errors when actually trying to login to the customer account more than admin but believe it still applies.
Im having the exact same problem as this user:
http://www.magentocommerce.com/boards/viewthread/284012/
Although no solution was posted.
When I try and create a new order , all works fine except I cannot choose a custom group. Checking anything else in the dropdown results in the loading dialog , and it then resetting to the default value.
No errors are thrown in the logs.
This , it seems is related to payment gateways. Specifically in this case , SagePay. Removing the SagePay plugin solved the issue.
In 1.3 we were using a different plugin than what works in 1.4.
I'm trying to set up an MVC application that will service several facebook applications for various clients. With help from Prabir's blog post I was able to set this up with v5.2.1 and it is working well, with one exception.
At first, I had only set up two "clients", one called DemoStore and the first client, ClientA. The application determines what client content and facebook settings to use based on the url. example canvasUrl: http://my_domain.com/client_name/
This works for ClientA, but for some reason when I try any DemoStore routes I get a 500 error. The error page points to an issue with the web.config.
Config Error:
Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to 'facebookredirect.axd'
I am able to add additional clients with no problem, and changing DemoStore to something like "demo" while using the same facebook application settings works fine also.
Working calls:
http:// localhost:2888/ClientA/
http:// localhost:2888/ClientB/
http:// localhost:2888/Demo/
Failing call:
http:// localhost:2888/DemoStore/
I was thinking this might be an MVC issue, but the Config Error points to the facebookredirect handler. Why would the SDK try to add this value to the config during runtime, and only for this specific client?
Any insight would be greatly appreciated.
I managed to figure out what went wrong here. Silly mistake..
After I had set up the application routes to require the client_name I changed the Project Url in the project properties to point to demostore by default. When I hit ctrl+S a dialog popped up that I promptly entered through without reading.
When I changed the Project Url, IIS Express created a new virtual directory for the project. This was the source of my problem. Why? I'm not sure, but once I removed the second site from my applicationhost.config I was able to access the DemoStore routes.
Moral of the story: read the VS dialog messages!