Is there any quick and easy way to make the backend go to /admin instead of /refinery?
I looked through the docs as well as looked at the gem itself to find any information on this, however I came up with nothing. If this is not possible without major hacking, that would be great to know as well, to be able to pass that info onto my client (i personally could care less about the route).
I added the following line to config/routes.rb. Be aware that this must come before mount Refinery::Core::Engine, :at => '/':
match '/administrator' => redirect('/refinery')
# inserted by Refinery:
mount Refinery::Core::Engine, :at => '/'
This will redirect http://example.com/administrator to http://example.com/refinery which will open up the backend.
Sorry for the delayed response, but I was running into the same problem myself recently.
Instead of redirecting you can also configure the route directly in refinery core config, see here: How do I change the Refinery CMS admin path?
Related
The problem:
I have a express backend/angularjs frontend web app hosting all of my teams documentation for our users. We frequently need to post links to a specific question (all linked as ids) to our users in Slack. ex. helpapp.com/productTheyNeedHelpWith#QuestionLinkedTo the problem is that when the link is clicked from slack, not when copy/pasted, Slack launches a new browser window/tab to helpapp.com/productTheyNeedHelpWith%23QuestionLinkedTo.
This breaks ngRoute as it no longer recognizes /productTheyNeedHelpWith as the path to load the correct page for and the user gets sent to our home page instead.
Thoughts on possible solutions:
I'd like to solve this issue either in the ngRouting itself by somehow updating the path by replacing %23 with # before $routeProvider does it's magic, or by somehow capturing the full url in app.js and updating it or redirect to an updated version before we've rendered a page view at all.
currently I've set a workaround by using a ng-init event to check the url and, if %23 is found, update it and replace it with the correct extension but this causes an odd double load that leads to a poor user experience.
Final Thoughts:
As I'm not sure of the best way to go about this, and because our code is proprietary, I'm avoiding posting to much 'example code' that may not be relevant but am happy to provide any parts of it that you, wonderful stackoverflowers, may request. Thank you in advance for your assistance.
I'm pretty new with AngularJS and server config stuff, and this is a problem I haven't found a satisfactory solution so far.
I would like to be able to use the HTML5 url on a website (without hashbangs), so that I could use addresses like "mydomain/contact" to navigate (I'll stick with the "contact" example for simplicity).
To do that, as I've found so far, one should do two things:
Enable HTML5 on the client side
Enable the HTML5 format on the app/app.js file (also adding the dependency)
$locationProvider.html5Mode(true);
It makes possible to click on links and get the proper url. Still, it doesn't allow someone to access directly the HTML5 url. To get to the "contact" page, I still can't directly access "mydomain/contact" (we get a 404) and I know it makes sense. To solve this, it is still necessary to implement something server-side.
Server-side config
Configure the server to respond with the right file, i.e., I should configure the server to make it respond the same way when I request "mydomain/#/contact" and "mydomain/contact".
The last item is where I'm stuck. I've found many answers like this: "you should configure your server" (they assume the reader already knows how to do this. I don't), but I can't find a complete example on how to do that or where to put any needed files.
I'm using AngularJS 1.6.x and npm 3.10.9 (npm start). My question is: is there any complete example on how to fully use HTML5 urls with AngularJS?
The only problem that exists is that angular can't handle requests it doesn't receive. You need some catch-all so that all routes (/contact etc) are passed to your main index-file.
When you say .htaccess I assume apache. Even so I'd still put nginx in front of apache since it's lightweight and easy to configure (at least compared to the apache behemoth). Sorry, I know that is a very opinionated answer. Anyway with nginx the entire config could look like this:
# usually this file goes in /etc/nginx/conf.d/anyfilename.conf
# but it might vary with os/distro.
server {
listen 80
root /var/www/myapp;
location / {
try_files $uri $uri/ index.html;
}
# And if you want to pass some route to apache:
location /apache {
proxy_pass http://127.0.0.1:81; # Apache listening on port 81.
}
}
I'm sure the same can be achieved with apache alone, but I couldn't tell you how. But perhaps this can be of help: htaccess redirect for Angular routes
There are so many silly toolpacks and utilities I've wasted time learning in my life, but nginx is the one tool I'll never regret I picked up.
I recently migrated an old Wordpress site over to Joomla and it has created an obscene amount of 301's in the Redirects component and I would like to change these to 404's as 99% of them have no relevance anymore (its as if anything and everything from the last site was indexed!). Does anyone know of a way to do this without having to trawl through 5400 of them..?
Please take a look on this tutorial https://joomlaseo.com/checklist/reroute-non-existing-url-s-with-301-redirects. For url redirects you can also use the build in joomla components: link. Make sure that first you have to apply any major changes on test site(i.e, make the live copy and test it then deploy to live), because its always good practice.
Thanks & Regards,
Kaif
I am trying to make Play2 to play nice with AngularJS. Play2 will have no knowledge of AngularJS because I use Yeoman for frontend dev.
The only part I want to get down is to rewrite the url in case the user refresh in HTML5MODE. I have in my routes file in the last line
GET /*path controllers.Default.redirect(to = s"#!/$path")
However, this does not work. First of all, it seems that in routes file, using string interpolation is not allowed as $path cannot be resolved. Moreover, using # in string gives error, too, because # is the start of comment.
I can create a controller action for this route just to append "#!" to the path like this:
GET /*path controllers.Application.redirect(path: String)
/* in Application controller */
def redirect(path: String) = Action {
Redirect(s"#!/$path")
}
But I prefer to keep it very clear in the routes file, like in Ruby on Rails, I can just do
get '/*path' => redirect("/#!/%{path}")
Could you share with me your tricks and best practices?
Thanks
You're probably better off doing this rewriting in Apache or Nginx - a web server's URL rewriting capabilities are much more robust than Play's. See the Play documentation for how to set up a web server in front of Play, and then check the docs for the web server for how to set up the rewriting you want.
I have a client who has many blog customers. Each of these WordPress blogs calls a plugin that provides a product link. The way that link is composed looks like this:
{website}/wp-content/plugins/prodx/product?id=432320
This works fine on all blogs except two. On those two, when you try to call the URL, you get a 404.
So, I disabled all plugins except prodx and reverted the theme to default (Kubrick), thinking perhaps a plugin intercept with add_action() API was doing this, such as intercepting URLs and redirecting them. However, this did not help.
So, I upgraded the WordPress to the latest version. Again, didn't fix.
So, I checked permissions, comparing with a blog that worked just fine. Again, didn't fix.
So I replaced the .htaccess, using one from a working blog. Again, didn't fix.
So I replaced all the files using some from a working blog that was identical to this one, and then restored the wp-config.php file back so that it talked to the right blog database. Again, didn't fix.
Again I checked permissions meticulously, comparing to a perfectly working blog. Again, didn't fix.
So, I created a test.php that looks like so:
<?php
print_r($_GET);
echo "hello world";
I then copied it into another plugin folder and used my browser to get to it -- again, 404. So I copied it into the root of wp-content/plugins and tried to call it there -- again, 404. So I copied it into wp-content -- again, 404. Last, I copied it into the root of the WordPress blog website, and this time, it worked!
Doesn't make sense.
I started to think that perhaps something was going on with /etc/httpd/conf/httpd.conf for this customer, but the only thing I saw different in their for this customer was the IP address was different than the customer's blog that worked. Each customer gets their own IP in this environment my client has built.
My client sysop is baffled too.
What do you think is going on? Is there something wrong in the WP database for this customer? Is there something wrong in httpd.conf?
You could check for bad URLs in plugins' options in the WP options table using phpmyadmin (and compare other aspects of each blogs' options) which might be already available at your host, or as a plugin: WordPress › Portable phpMyAdmin « WordPress Plugins. Or delete the plugins' options with Clean Options to completely "reset" the plugin (if the plugin uses options): Clean Options « WordPress Plugins
You should look into your server's error log, there should be an explanation. If not, turn up debugging levels etc. That said, the plugin really shouldn't link to the file in the plugin dir, it should use the wordpress rewrite class http://codex.wordpress.org/Function_Reference/WP_Rewrite
I think the problem was that the URL was too long. Here's some great info about that:
http://www.boutell.com/newfaq/misc/urllength.html
And for some reason the blog was getting a 404 instead of a 413.
The fix was that I used gzcompress to shorten my long product ID (which was a cloaked URL), then bin2hex. So I made the URL like so:
http://myblog.com/item/789ccb282929b0d2d72f2f2fd7cb4ac92fcc4faed44bcecfd54fcec94cced63536373334b730d7353430333334b530b60f0df2b1cd00ea503576543572032290befcb2d4a2e292fce46c904e90b0b15b1a50854b9aaa915980a3bb2b901910e4ef12ea1c0214f00f0ef60e058a181a199b5b18999b0100194725b4
From there, I had my plugin add an init handler to hijack the URL, inspect it, and redirect. That function looks like this:
add_action('init','hijackURL');
function hijack_URL() {
$sURL = $_SERVER['REDIRECT_URL'];
if (empty($sURL)) {
$sURL = $_SERVER['REQUEST_URI'];
}
if (strpos(' ' . $sURL, '/item/')>0) {
$sID = str_replace('/item/','',$sURL);
$sID = trim($sID);
if (empty($sID)) {
require('../../../wp-blog-header.php');
$sBlogURL = get_bloginfo('wpurl');
header('HTTP/1.1 302 Moved Temporarily');
header("Location: $sBlogURL");
exit(0);
}
$sID = pack('H*', $sID);
$sURL = gzuncompress($sID);
header('HTTP/1.1 302 Moved Temporarily');
header("Location: $sURL");
exit(0);
}
}