I've my site structure as below
root
|
|-- ProjectDir
|
|-- fonts
| |-- my-webfont.woff
|
|-- css
| |-- vendor
| |-- my-style.css
|
|-- rent.html
In "my-style.css" file, font is linked using a site-root-relative url
url('/fonts/my-webfont.woff')
I use a local webserver to view
http://localhost/ProjectDir/rent.html
But my fonts are not loading and when I try to load
http://localhost/fonts/my-webfont.woff
it shows a 404 Error (File Not Found).
You can see the my git repo here: https://github.com/abhisekp/House-Rent-Calculator and see the fonts/ directory.
And loading the font file using the web server shows 404 Error. See here: https://abhisekp.github.io/fonts/fontawesome-webfont.eot
What's wrong with all this? My local server also behaves this way.
Try using this:
url('../../fonts/my-webfont.woff');
Thanks everyone. I found the bug.
Actually, the problem was the root itself. When viewing using https://abhisekp.github.io/House-Rent-Calculator address, the root is "abhisekp.github.io/" not "abhisekp.github.io/House-Rent-Calculator/" hence the #font-face urls refer to the former rather than the later.
The fonts lies under "House-Rent-Calculator/" directory. I fixed it by using a relative link (safe for everything if "fonts/" & "css/" directories are not changed frequently).
No more root-relative links as I test using various servers and my "House-Rent-Calculator/" directory might be anywhere in the server.
Better be safe than sorry! ;-)
Related
I tried the official installation guide for installing wagtail locally :
first by creating a website
second by integrating wagtail into a new website
Each time it seemed to work fine functionally but all the CSS was broken (see pic down)
I tried to do "manage.py collectstatic", it told me that 2/3 hundred files have been copied, I emptied the cache of my browser, loaded the page again, no change.
In the console it seems that the files are sent :
[14/Jul/2019 10:16:54] "GET /static/css/welcome_page.css HTTP/1.1" 200 3003
I restarted several times the tutorials from the beginning making sure I do each step exactly as described, nothing changes. When I begin with a new django project, the base django css is working before I add wagtail. I m using Python 3.6.8, Django 2.2.3 and Wagtail 2.5.1. What am I doing wrong ?
To answer #Dan Swain comment :
Settings.py file :
https://pastebin.com/zZqDesnr
Ok so simply my django-wagtail server was serving css but with an incorrect mimetype. My browser received the css but because of the wrong mimetype it didn t apply them
I had to add :
import mimetypes
mimetypes.init()
mimetypes.types_map['.css'] = 'text/css'
To my settings files and everything worked fine
One standard Wagtail folder structure includes a settings folder (not just a settings.py file). Inside the settings folder you would find base.py, dev.py, local.py, and production.py. You are using, instead, a plain settings.py file that is at the same level in the directory structure as your wsgi.py. Inside your settings.py you have a BASE_DIR declaration that is typically used in the settings folder setup:
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
I think that your problem will be fixed if you change that line to:
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
I found missing 3 style files by F12 debugging. Copy the style folder to the target folder. From wagtail-master\wagtail\admin\static_src\wagtailadmin\scss to wagtail-master\wagtail\admin\static\wagtailadmin\css. That solve my style error.
if CSS is not working in admin panel in wagtail. you should check your nginx setup at first. in nginx there are should be such configurations:
location /static/ {
alias /home/path_to_project/project/staticfiles/;
}
please give attention, there should be alias not root
I have installed symfony 4 on my shared hosting.
My structure is like this:
ROOT
|
|-- public_html
|
|-- tst
|-- tst
|
|-- bin
|-- config
|-- src
|-- translations
|-- var
|-- vendor
|-- composer.json
|-- composer.lock
|-- binsymfony.lock
I moved index.php from the public folder to the public_html/tst folder and changed the paths inside that file to match the new structure:
require __DIR__.'/../../tst/vendor/autoload.php';
Now, when running http://mysite/tst, I get the homepage of the site as expected. But when I try another route (other than "/"), I always receive a 404 page not found.
Does this have something to do with privileges of am I missing something?
I figured this one out myself, but if someone tell me how to deploy a Symfony 4 application to a shared hosting, please tell me! I think other people will like this too...
You can create symlik for Public. The method you try can lead to problems.
# Enter Directory Root
cd /root_dir
# Create Symlink
ln -s public_html tst/public
I'm having a text file in Resource folder and my robot script in sibling folder namely Test, I need to use the relative path otherwise I need to specify the path explicitly once I changed the project location.
TEST PROJECT (Root folder)
|
|_____ Resource (folder)
| |_____ MyProfile.txt
| |_____ MyPicture.jpg
|
|_____ Test (folder)
|_____ MyTest.robot
I want to access the MyProfile.txt in MyTest.robot using relative reference instead of absolute path.
Kindly assist me.
We can give the Relative path by using the following approach
${CURDIR}${/}..\\Resource\\MyProfile.txt
The ${CURDIR} will return the path of where you are using this code, then we need to back track using the navigation operator ..\\
But if you use ${EXECDIR} will return the path of the file is executing.
${EXECDIR}${/}..\\Resource\\MyProfile.txt
Here the code and execution both are handled in a single file, so both the code will give you the appropriate location of MyProfile.txt
or another way, you may add the project root folder to the sys.path. it will search up the referenced resources from the root folder.
Serverspec is used to check on several servers. Therefore the recommend structure of roles is used:
|-- Rakefile
|-- spec
|-- app
| -- ruby_spec.rb
|-- base
| -- users_and_groups_spec.rb
|-- db
| -- mysql_spec.rb
|-- proxy
| -- nginx_spec.rb
|-- spec_helper.rb
To read the data and structure I use a yaml-file.
On the serverspec website is in the Rakefile inside the Raketask the following:
ENV['TARGET_HOST'] = host
Why should I set the host as an environment variable? Wouldn't a local one be enough?
The default spec helper uses it to target hosts for the net-ssh gem. You can refactor the host targeting code in the spec_helper to not even use it if you want and then just use host_inventory for the hostname.
Note the following:
https://github.com/mizzy/serverspec/blob/master/lib/serverspec/setup.rb#L276
https://github.com/mizzy/serverspec/blob/master/lib/serverspec/setup.rb#L292
Despite the anonymous downvote, this is absolutely the correct answer.
My team is currently working on an ASP .NET website. We are one of the first teams in our organization to use TFS2008 for source control. When I joined the project, it had already been active for a few months. Below is a diagram of the basic file structure we are using in TFS:
$/TfsProject/
|
| /* Contains our in-house class libraries. */
|-- Common/
| |
| |-- Extensions/
| | |-- Extensions.csproj
| |
| |-- Loggers/
| |-- Loggers.csproj
|
| /* Contains third-party libraries. */
|-- Library/
| |
| |-- EnterpriseLibrary/
| |
| |-- v4.1/
| |-- Microsoft.Practices.EnterpriseLibrary.Common.dll
|
| /* Contains the website itself. */
|-- Site/
|
|-- Packages/
| |-- Packages.csproj
|
|-- Website.root/
|
|-- Website/
|-- Website.sln
|
|-- Website/
| |-- Website.csproj
| |-- Default.aspx
|
|-- WebsiteUnitTests/
| |-- WebsiteUnitTests.csproj
|
|-- WebsiteWebControls/
| |-- WebsiteWebControls.csproj
|
|-- Utilities/
|-- Utilities.csproj
The main website solution (Website.sln) currently contains fifteen projects (including each of the .csproj files displayed in the diagram). Yesterday a decision was made that the projects contained in the Common directory should be moved into their own solution, and we should include them in the Website by referencing the compiled DLLs instead of the projects themselves. Anytime one of the Common projects is updated, all other projects that use it should begin using the latest version with minimal effort.
Is there any easy way to implement this, based on our current hierarchy? I have read the TFS patterns & practices guide, but implementing any its suggestions would require significant changes (as well as updating all of our projects and solutions). Also, our organization is waiting until TFS2010 is released before they enable Team Builds -- so they're unavailable to us.
The more "portable" solution would be to have a build specifically for the shared projects/solutions. The last step of those builds is to check in the binaries into a publishing folder (possibly under /libraries). When getting latest for the client projects (those referencing the binaries) you will end up pulling down the latest binaries. You don't lose the ability to branch the client projects and team members are free to map folders as they choose.
I will say as a whole, you should reconsider your folder structure. It doesn't allow for a very flexible branching structure. You appear to be using your TFS repository much like many VSS users historically have: As a versioned file system.
A solution that may work is to have
the projects in Common all output to
the same directory ("C:\temp\dlls"),
rather than each local /bin folder.
That directory can then be added to
the Web Project solution. All of the
references to the DLLS should be made
to the common folder pulled from TFS.
That directory can be added to TFS as
a folder. Everyone on the team will
have to have the folder mapped
locally with the same relative path
to the solution file.
The place where the "minimal effort"
piece breaks down is that the files
will have to be checked in/out when
compiled. The rest of the team would
then have to GetLatest. The GetLatest
requirement may actually be better,
because you don't want changes forced
to you while you are in the middle of
developing.
You basically end up having a folder with compiled dlls added to the web project solution. That is also the same folder that all the Common dlls are built to. That folder is where all the projects in the web solution reference the Common Dlls. When someon rebuilds, they have to check out the dlls in the folder, build and then check back in. When a developer wants the latest, they call GetLatest on the folder and rebuild their projects.
This actually worked for us in a similiar situation where we had compiled dlls to reference. The difference for us is that the compiled dlls chagned so infrequently, that the whole "GetLatest" paradigm never came into play.