I designed a site using Wordpress, and have been trying to get a Codeigniter form app integrated with it, with all the corresponding URLs.
I put the CI app in the root folder of the Wordpress site. The folder is named "Chile" (it's a series of forms separated by LATAM countries). I changed the .htaccess file to include /chile where necessary. I also added:
require '../wp-load.php';
to the CI index.php file.
I can now load some of the essential urls in the CI app, but they don't seem to be routed properly.
the base url is set to:
$config['base_url'] = "http://".$_SERVER['HTTP_HOST'];
$config['base_url'] .= preg_replace('#/+$#', '', dirname($_SERVER['SCRIPT_NAME'])).'/';
the site is www.dermusikplatz.com. the form is located under www.dermusikplatz.com/chile/applications which i can reach by manually entering that. but when i try to submit the form, the url appears strangely as www.dermusikplatz.comapplications/save. In general, the urls constructed by the controllers and views just don't seem to be set up properly.
I've looked up the documentation regarding routing and have tried creating a $route rule. but i'm not sure what to route from and to what exactly. I've also seen various threads that suggest using MY_URL_helper to change the value of 'site_url' to 'ci_site_url', to avoid any redundancies between the value that Wordpress and CI have for that, but i'm not sure where to even start with that, even after checking out the helper documentation.
I've also tried going in and changing each path value in statements like these from:
$this->load->view('applications/form');
to:
$this->load->view('/chile/applications/form');
but I understand that makes little sense as that directory doesn't exist. I assumed that changing the .htaccess file and the base_url would cover it, but there seems to be much more to it than that.
I'm a little lost here, and not super familiar with Codeigniter.
If anyone can help set me in the right direction at the very least, I would really appreciate it. Thanks.
$config['base_url'] = "http://".$_SERVER['HTTP_HOST'];
Change that to:
$config['base_url'] = "http://".$_SERVER['HTTP_HOST'] . '/Chile/';
It is worth noting that if you are hosting on Linux the 'Chile' must be the exact same case as your folder is called. So, if it is 'Chile', do not call it 'chile'
Related
On my local server, I have setup a website using Codeigniter which opens up fine using below URL
I have a different kind of query regarding rewriting URL
http://localhost/mywebsite
Actually the real URL is below
http://localhost/mywebsite/page/
Which I want it to work as root url as
http://localhost/mywebsite
So I have done it by adding it as default controller in config.php
But now I have another URL as
http://localhost/mywebsite/page/mypagename
Which should open as
http://localhost/mywebsite/mypagename
How can I do it?
You can define a custom route in /system/application/config/routes.php - for example:
$route['abc'] = 'controller_name/abc';
Then, http://mydemosite.com/abc
goes to http://mydemosite.com/controller_name/abc
see https://ellislab.com/codeigniter/user-guide/general/routing.html for more information of URI Routing.
I hope this can be helping you.
I got it solved using routing method as below under config/routes.php
$route['([^/]+)/?'] = 'page/$1';
I have a newsletter 3rd party system. It has been working really well however I have come across an issue which I'm hoping is a really easy fix.
So this is the root structure of my website
FTP SERVER
/index.php
/news.php
/shane/shane_about.php
/mailist/globals.php
/mailist/mailbar.php
/mailist/mailbar8.php
So I have an input box which allows me to register for a newsletter. It works a treat on index.php and news.php however screws up the whole page on shane_about.php because its in a child directory shane.
Now the problem is in the globals.php
<?php
$main_dir = "maillist/";
$website = "http://www.mysite.com/";
$relative_string="index.php?page=mail&";
$absolute_path="/hostingcompanyserver/something/something/something.com/maillist/";
$lang="lang_english.php";
So I changed the variable $main_dir to "../mailist/"
This then worked on the shane/shane_about.php, then index.php and news.php had the same issue (it screwed up).
I'm sure the solution is very basic, any thoughts would be appreciated.
Thanks Chris
Change $main_dir to an absolute path.
If it's the same as $absolute_path you won't have this problem.
$main_dir = "/hostingcompanyserver/something/something/something.com/maillist/";
The problem at the moment is index.php and news.php look inside maillist as defined by $main_dir. shane_about.php looks inside /shane/maillist/.
You then told it to go up a directory to maillist with ..maillist/. This meant shane_about.php was looking in the right place but index.php and news.php weren't.
By using an absolute path all files look in the same place.
I am working on a drupal site. The current issue is that when a link is created either by using the url() or the base_path variable, it works ok on local development environment but when the very same code is put on the server, the url prepends node string in the path.
e.g. the path is <drupal site>/latestnews . The generated path is <drupal site>/node/latestnode and when clicked, it shows the page not found error. However would like to mention that the links work fine (i.e generate correct path) when clicked from the home page.
any help would be appreciated. If it helps, I am using Pantheon hosting for testing.
Does the server by chance have the pathologic module enabled? That module's job is to rewrite links for different locations. It may be misconfigured. If it is enabled, try disabling it, or adjusting its configuration in each of your text formats (admin/config/content/formats).
Have you checked if the $base_url variable in the 'sites/default/settings.php' file has the correct value? According to documentation "if Drupal is generating incorrect URLs on your site, which could
* be in HTML headers (links to CSS and JS files) or visible links on pages
* (such as in menus), uncomment the Base URL statement (remove the
* leading hash sign) and fill in the absolute URL to your Drupal installation."
I had the exact same problem and fixed it.
Initially, my site was NOT using clean urls. When I ENABLED clean urls and rewrote my links so that they weren't preceded by the string "?q=", this broke my hard coded links. This is because when clean urls are NOT used, pages appear to be in the root directory, but when clean urls ARE used, they appear to be inside of folders.
The following example shows how updating a page to use clean urls can affect it.
Clean_urls_DISABLED
Page: SITE?q=node/7
Hard_coded_link_in_page: ?q=node/9
Link_displayed_in_browser: SITE?q=node/9
Clean_urls_ENABLED
Page: SITE/node/7
Hard_coded_link_in_page: node/9
Link_displayed_in_browser: SITE/node/node/9
Notice that the page that was updated to use clean urls, has "node/node" in its link when it is displayed in the browser.
The solution is to prepend "../" to all hard coded urls (for pages other than your front page). That way hard coded links for other contents, such as images, will work as well.
Clean_urls_ENABLED
Page: SITE/node/7
Hard_coded_link_in_page: ../node/9
Link_displayed_in_browser: SITE/node/../node/9
Hard_coded_image_source_in_page: ../sites/default/files/img.jpg
Image_source_in_browser: SITE/node/../sites/default/files/img.jpg
This will work for hard coded paths for links, images, and any other elements that contain paths referencing files/documents.
I want both index.php included, and index.php excluded from my URIs to work smoothly on my site. I need it because of uploadify not working, and it is giving me a HTTP error.
It works if I have changed this
$config['uri_protocol'] = 'AUTO';
to this
$config['uri_protocol'] = 'QUERY_STRING';
, but then whole system is not working properly.
For your assets, first, on config.php set the $config['base_url'] to your website URL.
Then, when linking to assets on which you do NOT want index.php, just use the function base_url
<?php echo base_url("assets/uploadify/uploadify.swf"); ?>
// Generates http://URL/assets/uploadify/uploadify.swf
Follow the link in the comment from Indranil above to remove index.php from your URIs by modifying your .htaccess file.
Here is the address again for reference:
http://codeigniter.com/user_guide/general/urls.html
Keep in mind too that this can vary from host to host in the way that it needs to be formatted, so follow up on that with your hosting service. Most usually have guides that show you how to configure this properly.
I'd also like to know how you're using your links, but I'll go ahead and explain what I think may be happening to you. If you're doing any kind of link/anchor or redirect() using the URL Helper in CodeIgniter, then make sure you're using the right function to execute those actions. Here's what I mean:
The site_url() function/method will always include index.php in your URIs. Here's an example using the site name http://example.com as your website's domain.
<?php echo site_url('home') ?> will turn into http://example.com/index.php/home
While base_url() function/method will always exclude index.php unless you include it. Here's an example using the site name http://example.com as your website's domain.
<?php echo base_url('home') ?> will turn into http://example.com/home
and
<?php echo base_url('index.php/home') ?> will turn into http://example.com/index.php/home
Keep in mind that using these functions/methods are only effective AFTER you have properly modified your .htaccess file.
Here is the link that shows you a more in-depth difference between the site_url() and base_url() functions.
http://codeigniter.com/user_guide/helpers/url_helper.html
I hope this helps!
I have a website that responds on *.domain.com.
Going to x.domain.com or y.domain.com should produce the same web page.
What * is I do not know, but it is and important piece of info since we track things based on it.
When moving to wordpress we ran into a pretty severe problem. It seems to generate links (using get_page_link) with the domain which is set in the admin.
This will not work for us because we can't find a way to tell wordpress to generate links without the domain (why does it do this anyway?!) and every time a link is clicked the browser goes from: x.domain.com to domain.com (since domain.com is what we have in the admin).
Unfortunately WordPress is architected such that it is really hard to get rid of the domain component of URLs. But all is not lost! Read on as the answer to your question requires a bit of background.
The WordPress team made the decision to require the user of a site to hardcode the site domain either in the database via an admin console, which you can see in the following screen shot, of via PHP which we'll discuss below:
You might ask what the difference is between the the two URLs? Even I find it confusing because I almost never need anything other them to have them both set to the root URL and as it's not important for your question I'll just gloss over that detail. If you are interested though you can learn more here:
Changing The Site URL
Editing wp-config.php: WordPress Address (URL)
Giving WordPress Its Own Directory
Moving along, the other option is to hardcode the two PHP constants WP_SITEURL and WP_HOME in the /wp-config.php file which can be found in the root of a WordPress installation. Those two lines might look like this in your /wp-config.php file:
define('WP_HOST','http://domain.com');
define('WP_SITEURL','http://domain.com');
The good news is that you can define both of them dynamically based on the current domain your site is serving from (I'm going to assume you have both your DNS server and your Apache web server configured for wildcard DNS.) You can use the following code to match any subdomain name consisting of letters and numbers:
$root_domain = 'domain.com'; // Be sure to set this to your 2nd level domain!!!
$this_domain = $_SERVER['SERVER_NAME'];
if (!preg_match("#^([a-zA-Z0-9]+\.)?{$root_domain}$#",$this_domain)) {
echo "ERROR: The domain [$this_domain] is not a valid domain for this website.";
die();
} else {
define('WP_HOME',"http://{$this_domain}");
define('WP_SITEURL',"http://{$this_domain}");
}
The bad news is you may have some "artifacts" to deal with after you get it working such as how URLs are handled for image URLs stored in the database content (which may or may not end up being a problem) or for Google Maps API keys, etc. If you have trouble with them let me suggest you post another question here or even better at the new WordPress Answers Exchange also run by the same people as StackOverflow.
As for telling WordPress how to generate links, there are filters you can "hook" but in my quick testing I don't think you need it because WordPress will generate the links for whatever domain happens to be your current domain. Still if you do find you need them you can do it although be prepared to be overwhelmed by all the add_filter() statements required! Each one controls one of the different ways links can be generated in WordPress.
Here is the hook filter function and the 40+ add_filter() calls; you might not need them all but if you do here they are:
function multi_subdomain_permalink($permalink){
$root_domain = 'domain.com';
$this_domain = $_SERVER['SERVER_NAME'];
if (preg_match("#^([a-zA-Z0-9]+)\.?{$root_domain}$#",$this_domain,$match)) {
$permalink = str_replace("http://{$match[1]}.",'http://',$permalink);
}
return $permalink;
}
add_filter('page_link','multi_subdomain_permalink');
add_filter('post_link','multi_subdomain_permalink');
add_filter('term_link','multi_subdomain_permalink');
add_filter('tag_link','multi_subdomain_permalink');
add_filter('category_link','multi_subdomain_permalink');
add_filter('post_type_link','multi_subdomain_permalink');
add_filter('attachment_link','multi_subdomain_permalink');
add_filter('year_link','multi_subdomain_permalink');
add_filter('month_link','multi_subdomain_permalink');
add_filter('day_link','multi_subdomain_permalink');
add_filter('search_link','multi_subdomain_permalink');
add_filter('feed_link','multi_subdomain_permalink');
add_filter('post_comments_feed_link','multi_subdomain_permalink');
add_filter('author_feed_link','multi_subdomain_permalink');
add_filter('category_feed_link','multi_subdomain_permalink');
add_filter('taxonomy_feed_link','multi_subdomain_permalink');
add_filter('search_feed_link','multi_subdomain_permalink');
add_filter('get_edit_tag_link','multi_subdomain_permalink');
add_filter('get_edit_post_link','multi_subdomain_permalink');
add_filter('get_delete_post_link','multi_subdomain_permalink');
add_filter('get_edit_comment_link','multi_subdomain_permalink');
add_filter('get_edit_bookmark_link','multi_subdomain_permalink');
add_filter('index_rel_link','multi_subdomain_permalink');
add_filter('parent_post_rel_link','multi_subdomain_permalink');
add_filter('previous_post_rel_link','multi_subdomain_permalink');
add_filter('next_post_rel_link','multi_subdomain_permalink');
add_filter('start_post_rel_link','multi_subdomain_permalink');
add_filter('end_post_rel_link','multi_subdomain_permalink');
add_filter('previous_post_link','multi_subdomain_permalink');
add_filter('next_post_link','multi_subdomain_permalink');
add_filter('get_pagenum_link','multi_subdomain_permalink');
add_filter('get_comments_pagenum_link','multi_subdomain_permalink');
add_filter('shortcut_link','multi_subdomain_permalink');
add_filter('get_shortlink','multi_subdomain_permalink');
add_filter('home_url','multi_subdomain_permalink');
add_filter('site_url','multi_subdomain_permalink');
add_filter('admin_url','multi_subdomain_permalink');
add_filter('includes_url','multi_subdomain_permalink');
add_filter('content_url','multi_subdomain_permalink');
add_filter('plugins_url','multi_subdomain_permalink');
add_filter('network_site_url','multi_subdomain_permalink');
add_filter('network_home_url','multi_subdomain_permalink');
add_filter('network_admin_url','multi_subdomain_permalink');
While brings us to the final point. There is functionality in WordPress that attempts to ensure every URL that is loaded is served via its canonical URL which in general is a web best practice, especially if you are concerned with optimizing search engine results on Google and other search engines. In your case, however, if you really do not want WordPress to redirect to your canonical URL then you need to add a redirect_canonical filter hook and tell WordPress not to do it.
What follows is the code to make sure any page that serves as "x.domain.com" stays on "x.domain.com" even if all the URLs are filtered to be "domain.com". That may not be the exact logic you need but I'm just showing you the building blocks of WordPress so you'll be able to figure out the logic that you require.
A few final details about this function call; parameters #3 and #4 refer respectively to the priority (10 is standard priority so this hook will not be handled special) and the number of function arguments (the 2 arguments are $redirect_url and $requested_url.) The other thing to note is that returning false instead of a valid URL cancels the canonical redirect:
add_filter('redirect_canonical','multi_subdomain_redirect_canonical',10,2);
function multi_subdomain_redirect_canonical($redirect_url,$requested_url){
$redirect = parse_url($redirect_url);
$requested = parse_url($requested_url);
// If the path+query is the same for both URLs, Requested and Redirect, and
if ($redirect['path']+$redirect['query']==$requested['path']+$requested['query']) {
// If Requested URL is a subdomain of the Redirect URL
if (preg_match("#^([a-zA-Z0-9]+).{$redirect['host']}$#",$requested['host'])) {
$redirect_url = false; // Then cancel the redirect
}
}
return $redirect_url;
}
That's about it. Hope this helps.
-Mike
do you have any control over your hosting? Maybe you can use the rewrite module in apache, if you are using apache.
In httpd.conf add:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^x\.domain\.com
RewriteRule ^(.*)$ http://www.domain.com/x/$1
RewriteCond %{HTTP_HOST} ^y\.domain\.com
RewriteRule ^(.*)$ http://www.domain.com/y/$1
You can change the way you pass the variable "v" too
RewriteRule ^(.*)$ http://www.domain.com/$1&var=v
I didn't try the code, but i'm pretty sure that at least it will open your mind to a new way to deal with this issue --one that doesn't involve so much coding.
Cheers.
A.