Welcome Guest, Not a member yet? Register   Sign In
404 not found!
#1

I am getting  a 404 error from this GET 

background.js:27 GET http://localhost/subit_backend.php 404 (Not Found)
background.js:27 XHR failed loading: GET "http://localhost/subit_backend.php".

            var xhr = new XMLHttpRequest();
            xhr.onerror = function() { alert('error'); };
            xhr.open("GET", "http://localhost/subit_backend.php", true);
            xhr.send(jsonResponse["email"]);

my Document Root in httpd.conf is:

DocumentRoot "C:/xampp/htdocs/sub_crud"

<Directory "C:/xampp/htdocs/sub_crud">

subit_backend.php is in my controllers directory. 

where is my path going wrong?
proof that an old dog can learn new tricks
Reply
#2

Controllers should be called without .php:
http://localhost/subit_backend

If you really want to call a .php file. You need to place it alongside your index.php file.
Reply
#3

I am not sure what you mean "alongside"? My main application is in the sub_crud directory. So when I type localhost at the browser, I guess it goes to sub_crud and finds index.php. I guess that index.php is pointing at my controller which is called Configure. In that same controller directory I have another controller called subit_backend.php. This is the one I am trying to get to run from my chrome extension by calling

xhr.open("GET", "http://localhost/subit_backend.php", true);
proof that an old dog can learn new tricks
Reply
#4

What *is* your folder structure, and what is your hosting configuration? (eg httpd.conf or https-vhosts.conf)
Your front controller (index.php) should definitely *not* be in the same folder as any of your controllers ... it would be in the "document root" defined by your hosting.
See https://www.codeigniter.com/user_guide/i...structions
Reply
#5

(This post was last modified: 03-14-2018, 04:10 PM by richb201.)

well, as I said the document root is c:/xampp/htdocs/sub_crud. Within the sub_crud dir
c:
xampp  
  htdocs
    sub_crud   << document root
       application  
           controllers
               Configure.php   <<main controller
A user of the main program enters localhost in the browser and the Configure controller runs. Eventually this thing will be hosted on Google Cloud but I am still developing the app.

I am not sure how to architect this.

My Chrome Extension has two functions: a) login b)submit
Login sends an email string to my localhost. The program on localhost gets the email address looks it up in my database and sends back some JSON data that the Extension uses to populate its popup.html. How should the executable that gets the email string be configured? This being a CI centric place I have had some comments to just use a controller and a model. I could probably set up a route in my Configure controller called login that can be called like this from the Extension

xhr.open("GET", "http://localhost/login/".emailaddress, true);

So this would use the same controller as my regular application (which is a Grocery Crud app). It is a little strange to me to use a CI application as a daemon, but I guess it could work? As long as every user running my regular old Configure app is running a separate process. In the "olden days" we would spawn threads for something like this, but I really want to do this as simply as modernly possible. So to recap, when a call is made to xhr.open("GET", "http://localhost/login/".emailaddress, true) a new copy of my controller will run the "login route". Right? Can I start execution on a new CI process from a xhr.open?
proof that an old dog can learn new tricks
Reply
#6

localhost/login could trigger a Login controller's index(), or it could be a login() method inside Configure, or it could even be the default app inside a "login" folder (thought that sounds awkward if "Configure" is your default).

If the intent of the login function is to return JSON, then I would set it up as a separate controller, though that is not a requirement.

If a method inside Configure, its signature would be login($email).
If a stand-alone controller, its signature would be Login::index() and you would need to pick off the email parameter explicitly.
If a stand-along controller, but you use a POST, then the signature would be Login::index() and you would use $this->input->post('email') to retrieve the parameter.

In all these cases, the logic would be something like:
Code:
 ... validate/retrieve user info
 header("Content-type: application/json");
 echo json_encode($user_info_to_return);

If "subit_backend" is referring to a controller, then "localhost/subit_backend" would normally resolve to "application/controllers/Subit_backend.php"

Hope this helps.
Reply
#7

>>If a stand-along controller, but you use a POST, then the signature would be Login::index() and you would use $this->input->post('email') to retrieve the parameter.

I created Subit_backend.php and put it in the controllers directory. What does it mean "the signature would be Login::index()"? Can you point me at some part of the documentation that describes setting up such a thing? I have no idea what "::" means.

thx
proof that an old dog can learn new tricks
Reply
#8

(03-15-2018, 12:43 AM)richb201 Wrote: >>If a stand-along controller, but you use a POST, then the signature would be Login::index() and you would use $this->input->post('email') to retrieve the parameter.

I created Subit_backend.php and put it in the controllers directory. What does it mean "the signature would be Login::index()"? Can you point me at some part of the documentation that describes setting up such a thing? I have no idea what "::" means.

thx

That is just a generic notation for the "index" method inside the "Login" controller.
It's probably more from the Java world than PHP, but I find it gets the message across.
See https://docs.oracle.com/javase/tutorial/...ences.html

If "Subit_backend" is the endpoint that you want to use for login, using its default method, then that signature would be "Subit_backend::index()", where the empty parameter list implies no arguments. If you want parameters for an "index" method, then you could set up a routing rule for that, or else extract the parameters programmatically.
See https://www.codeigniter.com/user_guide/g...llers.html
Reply
#9

(This post was last modified: 03-16-2018, 07:23 AM by richb201.)

Turns out that sub_crud is not my default localhost location: here is my routes.php. Login is for an admin to login. 

 I am using a Login in controller to start and then after an admin logs in I switch to Configure controller
$route['default_controller'] = 'users/login';
$route['404_override'] = '';
$route['translate_uri_dashes'] = FALSE;
$route['registration'] = 'registration';
$route['login'] = 'login';

In my httpd.conf I have:

DocumentRoot "C:/xampp/htdocs/sub_crud"
<Directory "C:/xampp/htdocs/sub_crud">

I have created a new controller called subit_backend.php that is sitting in my controllers directory.

This is its code:
   class register extends CI_Controller
   {

   public function __construct()
   {
       parent::__construct();

       $this->load->database();
       $this->load->helper('url');
         }


   public function register()
   {

   }

}

I also have a model called users.php that contains the login code. 

I put a break point at Break at first line in php script to see if it is getting initiated. I try typing the following at the browser
http://localhost/Subit_backend/register

and I still get error 404.
proof that an old dog can learn new tricks
Reply
#10

I see two problems...

1) The "default_controller" setting is used to define the name of the controller class to use inside a controllers folder; it is not meant to denote a controller and method. Your setting says to look for the "users/login" controller, which doesn't make sense.
This means that "http://localhost/login" could map to the default method of the Login controller or to "users/login" inside a folder "application/controllers/login".

2) If you want a controller "subit_backend", then "appllication/controllers/Subit_backend.php" needs to define a class "Subit_backend" and not a "register" class.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB