I'm trying to set up refinery cms to work in a apache/passenger with a sub uri. But when i access the site and admin area, i get a strange behavior (Images aren't loaded correctly, pages can't be edited, etc.)
I was wondering if sub uri are simply not supported or if there is some sort of workaround available
(running rails 3.0.3 and refinery 0.9.9)
The reason i want to do this is to have the capability of hosting multiple refinery based sites on the same server/ip port 80.. simply by putting them each on a different sub uri.
I realize this is a really old question... I am trying to do the same, and found this question.
I've installed Rails 3.0.11, along with refinerycms 1.0.9, and some images are broken (on Apache/Passenger).. digging a little deeper I found that the locations of all the images ref'd in CSS are hard-coded, I find this highly annoying.. but it is what it is. Apparently they're working to get the cms working with the asset pipeline, which would fix these issues.
In the meanwhile, you can override them in your applications public folder just fine; you'll find most of the css in the refinery-core gem..
For instance do: rake refinery:override stylesheet=refinery/refinery
and then open the override file it installed and then do a find-replace of /images/ with //images/ ..That worked for me.
ETA: Don't forget to delete the public/refinery/cache folder contents after making changes.
Related
I'm having a problem using Vaadin (in Eclipse) and its associated styling engine Valo, and the TouchKit package. I mention all of these because I'm not sure which, if any, is causing the problem. The name of my custom theme (which imports Valo) is simply "touchkit".
I have the project running on a Tomcat server on localhost and accessible in my browser. I wanted to tweak some of the CSS so I edited the appropriate file WebContent/VAADIN/themes/touchkit/touchkit.scss. After editing this file, I recompile the theme and see the appropriate changes in the generated file styles.css. Then I go to load up the application in my browser, and things get weird.
I can load the page and, using Chrome's developer tools, see that the page requests styles.css for download, as expected. It gets a 200 OK response from the server, but when I view styles.css, it contains just a single \n. This is also true in Safari. Even using cURL to download styles.css yields the same result. In the Eclipse editor, and when I inspect it in the terminal, styles.css is ~12,000 lines long. Why can't my browser or cURL get that data?
I can view similar project demos on Vaadin's own site and the stylesheet (which should be almost identical to mine) is loaded correctly. Also, other Vaadin projects on my localhost server have their stylesheets loaded correctly (though they do not use Valo). Compiling the theme in Eclipse yields no errors. Because the issue presents itself across a variety of graphical and non-graphical clients, I'm starting to think the issue is with Tomcat. But I can get to the directory from which Tomcat serves files and styles.css is correct in that folder too. There's no apparent reason that Tomcat would be serving a blank file.
You may have guessed from the description, but I'm working on a Mac. Any help is appreciated!
PS Mods - I also asked this question over at Superuser since it wasn't 100% a programming question. However, I'm new at Superuser and couldn't create tags for Vaadin or Valo, so I'm asking here where there might be a better chance of getting an answer.
Hard to say, since your are doing everything fine. My best bet would be the tomcat implementation you are using, maybe there's something weird there. Try upgrading to latest if it's not or to a previous version.
FYI I'm using Tomcat 7.0.55.
PS: your attempts are in run/debug from eclipse or have you made a .war form the project and deployed it with the Tomcat-Manager?
Regards
add below to your gwt.xml, and touchkit is not valo aware see https://vaadin.com/forum/#!/thread/8264224/8264223
<set-configuration-property
name='touchkit.manifestlinker.additionalCacheRoot'
value='src/main/webapp/VAADIN/themes/MyTheme:../../../VAADIN/themes/MyTheme' />
Here is my simple (I hope) problem:
I 'm running a web app with eclipse through tomcat 7. I use the classic servlet-model-jsp pattern. My problem is when I change something in the stylesheet (CSS) and restart tomcat and reload the page on the chrome, the new css is not loaded on the browser (I check it through the browser and i see the same as before the changes).
What is wrong and what can i do about it?!
Thank you in advance :)
I don't think this is a client issue. I think it is a bug in Eclipse/ Tomcat plugin. If you check the request.getPathTranslated() inside the servelet doGet method, it will be something like
C:\Users\YourName\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\
wtpwebapps\yourAppName\
So the tomcat running inside eclipse is serving up static content from there, which is different to the location of static content that you are editing, which is usually something like
C:\fullPathTo\yourAppName\src\main\webapp\static
Tomcat inside eclipse often neglects to update the static content from where you have edited it to the plugins... spot from where it serves it to your web page.
To solve the problem I use Beyond Compare or similar, and set up a compare between the directories
C:\fullPathTo\yourAppName\src\main\webapp\static
and
...\.plugins\org.eclipse.wst.server.core\tmp1\wtpwebapps\yourAppName\static
If css or other static changes (such as javascript files) fail to show up in the browser, just do a quick refresh of the Beyond Compare window, this will highlight the mismatches, copy them across manually, and you are good to go.
I know this is a hack but it works for me, till the eclipse guys get this sorted out.
I'm migrating an e-commerce app from an old php framework to ASP.NET MVC. Some products have links to other products in their descriptions. I wrote a small app to import everything from the old site to the new site and now I want to update those links too. I would like to make the links relative, but relative links won't work on localhost because the site is in a virtual directory.
Old link: http://domain/index.php?productID=1234
New link: /product/1234
The new link won't work in localhost because it will be translated to localhost/product/1234 instead of localhost/virtualdirectory/product/1234.
I've been googling for a solution for quite some time but I can't seem to find anything. Do you have any ideas about how to solve this problem?
I actually came up with a solution while writing the question, but I'm going to post this anyway, maybe you come up with a better solution.
Have you considered not running your app in a virtual directory? While it may be the default in Visual Studio, it can be changed.
The solution I came up with was using links like this: ../../product/1234
In Visual Studio, right-click on your project and click "Properties." Under the "Web" tab, enter the virtual path in the box that says "Virtual Path:"
For example, /MyVirtualPath
In your code, make sure that your links are written like "../MyVirtualPath/".
I installed the latest version of Orchard on my dev machine using a base url of localhost/frankgiotto. Then I moved the site to www.frankgiotto.com and updated my Base URL in the settings.
Site works perfectly. I love everything about it but the one thing is that all the links on every page are mapping to www.frankgiotto.com/frankgiotto/etc and I want simply www.frankgiotto.com/etc
This is driving me insane at the moment.. help anyone!?
p.s.. Yes, I made absolutely sure that Base Url is set to www.frankgiotto.com
Interestingly enough, www.frankgiotto.com/Blog and www.frankgiotto.com/frankgiotto/Blog both work and take me to the same place. Its the same with everything else on the site.
This is little out of context, but to make the orchard urls work without any issue on local just do the following
go to Web project
open property->Web
check for "virtual path", set it empty, and all will be fine
that will make the app run without "/", hence less chance for the above issue
Yes, that is a known issue unfortunately. This is because for now links and image addresses are just stored as plain HTML in the database. Ideally, they would be stored as logical references instead and could be rebased on the production server. This feature does not exist today so what we encourage people to do is to use a port rather than a virtual directory on their dev box if they are going to deploy at the root of a domain. This way relative urls just work. In your case I'm afraid you'll have to manually rebase the existing links and change your dev box configuration.
Howdy, I just installed dotnetnuke 5.06 on my server, say, the path is mydomain.com/dnn
I have a library independent of dotnetnuke that I have to run and it contains web services and various other httphandlers so I haven't tried to integrate it into DNN just yet. the library is located under mydomain.com/dnn/lib
The library worked fine on my old server running 5.04 and everything worked fine, but for some reason my new installation with 5.06 (windows 2008, sql server, iis 7.5) returns 404 when i try to access a page under mydomain/dnn/lib/, regardless of whether it's aspx, asmx...however images seem to work just fine, everything else either returns 404 or redirect to default.aspx in DotNetNuke. This has never happened before with my old site.
does anyone know what I'm missing here? any suggestion is be greatly appreciated.
There's was an issue introduced in DNN 5.5 that blocks those files when they're outside of the DesktopModules folder. DNN 5.6.1 fixed that to some degree (I'm fairly sure that aspx works now), but not completely. Looking at the linked issue, it may help/fix to turn off automatic portal alias mapping in your Site Settings.
Actually, the issue was fixed only in DNN 5.6.2, which is currently in beta. Version 5.6.1 still had this issue. There's a workaround that works in every situation: add the absolute url to your PortalAlias table. You'll have to do this by hand, because the Portals-tab doesn't allow aliases that root at the same level as an existing alias.
Another solution, if you can't wait for the new DNN version, includes adding the following code to the RequestFilterModule.vb and UrlRewriteModule.vb, which restores the existing behavior. This is not the fix that's applied to DNN 5.6.2, because programmers believe it is too much of a performance impact to check for file existence on every visit (which I consider odd, as several files are touched on every visit anyway, the main DNN cache uses file-based caching and in general, database access is slower than file access):
'Add this to the RequestFilterModule.vb (line #59)'
'and to UrlRewriteModule.vb (line #325)'
If File.Exists(app.Server.MapPath(Request.Url.LocalPath)) And Not _
Request.Url.LocalPath.ToLower.EndsWith(glbDefaultPage.ToLower) Then
'exit early when path is an existing path'
Exit Sub
End If
Obviously, if you apply this fix, you have to be careful with the next update of DNN.