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
Related
As I need an /about route in NextJS, I've created the following folder structure:
...
|
pages/
|
├── about/
|
├── index.js
|
├── AboutContent.jsx
Where AboutContent.jsx is just a component to help index.js with part of the logic. The problem is that the AboutContent.jsx has become a route:/about/AboutContent. How do I prevent non-index.js components to become routes?
Move it out of the pages folder.
pages folder must have only page components, rest of the components you can put in your src folder.
|
pages/
|
├── about/
|
├── index.js
src/
|
├── AboutContent.jsx
just import AboutContent from the src folder
You can colocate test files or other files used by components in the pages directory. Inside next.config.js, add the pageExtensions config:
module.exports = {
pageExtensions: ['page.tsx', 'page.ts', 'page.jsx', 'page.js'],
}
https://nextjs.org/docs/api-reference/next.config.js/custom-page-extensions
In BETA Next.js#13.0.x, you can move your pages and components to /app directory while it is still okay to keep the page components under /pages directory. But routes across /app and /pages directories should not resolve to the same URL path. It may cause a build-time exception. I recommend to upgrade your Next.js to the latest and put all pages in /app directory.
|
app/
|
├── about/
|
|-- AbountContent.js
├── layout.js
|-- page.js
|
ui/
|
|-- BaseComponent.js
Currently I have an analysis project which I treated as package.
So currently I have the following structure:
mycoolanalysispackage/
|-- .Rbuildignore
|-- .gitignore
|-- DESCRIPTION
|-- NAMESPACE
|-- inst
|-- vignettes
|-- R
`-- mycoolanalysispackage.Rproj
At the end I usually produce many Shiny applications as Rmarkdown-flexdashboard file with Shiny runtime.
-- app1/
|-- index.Rmd
-- app2/
|-- index.Rmd
My question is, in which package subdirectory should I put those application directories (along with their index.Rmd files)?
I also have local Shiny Server, what's the best way to link that Rmarkdown-flexdashboard app to that server?
As with everything else, you place them in a subfolder of the inst folder when developing the package. When the package is installed, all folders in the inst folder will be moved to the package folder, and hence can be used as subfolders. So
mycoolanalysispackage/
|-- .Rbuildignore
|-- .gitignore
|-- DESCRIPTION
|-- NAMESPACE
|-- inst
|-- app1/
|-- index.Rmd
|-- etc...
|-- R
`-- mycoolanalysispackage.Rproj
To access the files from within an R function, you can use system.file:
system.file("app1","index.Rmd",package = "mycoolanalysispackage")
will give you the exact path to the index.Rmd of app1. That result can then be used to deploy the app using the appropriate functions.
See also the manual Writing R Extensions (scroll down a bit)
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.
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! ;-)
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.