Monkey, glad you like it. Yes, the enabling of the init controller could probably be better documented, but if you notice, none of the example functionality is well documented. I work many hours a day, so I’ll put it on the list of things to do!
Next on the list is a contact form. You won’t find many sites that don’t have one, so it ought to be part of the package.
Looks like you have a “contact us” form in your Community Cart code (just found Community Cart via reading through some other threads). You’re going to keep me very busy checking all this wonderful code of yours out.
Looks like you have a “contact us” form in your Community Cart code (just found Community Cart via reading through some other threads). You’re going to keep me very busy checking all this wonderful code of yours out.
Yeah, but Community Cart is really not as good was I want it to be. I’m going to completely redo it at some point, but I just don’t have time right now.
There has been a lot of work done in Community Auth in the last week or so, and specifically in regards to the new “Deny Access” functionality, I’m hoping some will test it out and let me know if you find any bugs or issues. I know because this feature works specifically with a .htaccess file that there may be a good percentage of people that won’t be able to use it, but let me know how it goes, and what you think.
Also, there’s a new maintenance mode (not documented) found in /index.php. It allows you to set the ENVIRONMENT to ‘maintenance’ and show a custom maintenance mode page to everyone except devs whose IP addresses are listed in the developer IPs array.
Thank you to CroNiX for pointing out a bug in the init controller. Admin creation was causing an error because there was no `license_number` for the insert into DB. What’s really strange is that when I was testing at home, I still didn’t have the problem, but I just added the license number to the admin creation form, and nobody should have that problem anymore.
Another more important issue was resolved in a commit a few days ago:
Hey Brian - Been slowly making my way through the code - still a steep learning curve for a newbie. I believe I’ve found an issue I wanted to let you know about. Was working with the Manage Users, and noticed when I page to the next set of data, the results appear in multiple places on my page. Narrowed it down to the manage-users.js, which seems to be writing to any/all tables that are included on my page, as opposed to a specific table (such as “myTable” which you’ve defined in the manage-users.php view).
I looked at the javascript, but don’t know enough how to tell it to only manipulate a specific table.
Hey Brian - Been slowly making my way through the code - still a steep learning curve for a newbie. I believe I’ve found an issue I wanted to let you know about. Was working with the Manage Users, and noticed when I page to the next set of data, the results appear in multiple places on my page. Narrowed it down to the manage-users.js, which seems to be writing to any/all tables that are included on my page, as opposed to a specific table (such as “myTable” which you’ve defined in the manage-users.php view).
I looked at the javascript, but don’t know enough how to tell it to only manipulate a specific table.
So, have you made customizations to the page? Is so, you added at least one tbody tag? On line 75 of the js file, you will see that tbody is emptied out and replaced with the contents of ajax. So, if you add another tbody to the page, you could just add an id to the original tbody, and add the id to the js too. So, for example, if you added an ID of “whatever” to the tbody, line 75 of the js becomes this:
Yes, I’ve been making changes to learn the code and bring it into my own test website. I’m very grateful for the code, so don’t take my posts as complaints - just trying to learn and provide feedback.
The change you suggested didn’t work correctly, but got me on the right path. Ended up changing to use “#myTable > tbody” and then things began to work. The full line:
$(’#myTable >tbody’).empty().append(data.table_content);
Thanks for the quick response Brian, and again, for this code.
are there any known incompatibilities when it comes to servers? I have 2 very similar cpanel servers and community auth works fine on one but just shows a completely blank page on the other (0 bytes, just headers). I have configured it correctly and all that stuff.
I have tried everything I can think of that would cause this but nothing seems to help.
If anyone could point me in the right direction it would be much appreciated.
If it were me, I’d probably start by removing the call to is_logged_in() in the construct of the static pages controller. This controller is where the home page is generated from, and by removing is_logged_in(), you’d essentially have nothing going on with the authentication library. You could take it a step further by removing autoloaded stuff in config/autoload. By doing these things, you are really reducing it down to just plain CI. I’d be glad to take a look at it with you if you give me access. I haven’t heard anyone else say that there were server incompatibilities, so I’m leaning towards a corrupt file download or something….
Thanks for the pointers, they did send me in the right direction. Turns out it was an ‘i’ causing the problem.
Your database config file has mysqli as the default driver, the default CI one is mysql. It seems that was enough to stop the whole thing working for me.
I did however find a typo / bug in application/models/registration_model.php on line 201, you missed the ;
Thanks for the pointers, they did send me in the right direction. Turns out it was an ‘i’ causing the problem.
Your database config file has mysqli as the default driver, the default CI one is mysql. It seems that was enough to stop the whole thing working for me.
I did however find a typo / bug in application/models/registration_model.php on line 201, you missed the ;
Thanks for the help.
lazzymonk! Thanks for your feedback. I fixed those issues in the repository tip just now. Let me know if you find anything else, and again, thank you.
Only other thing that you may or may not want to add is some sort of notification that upload_directory is not writable. It made me stumble for seconds but could be more confusing for others.