I have a website running on Zend and I have a single file that is written from somewhere else and does not follow the Zend framework.
The file merely imports content from another site so it is ok that it has no user interface and only needs to be run. Ideally I want to run it from the website front end (a single button click). I don't want to go through and re-write the code to load as a native Zend file.
How can I achieve this? Where should I place the file? The project is in /var/www/projects/myproject, inside myproject there is the usual application, cache, data, extra, htdocs, log, nbproject folders. Under the application folder, as standard Zend, there are models, modules, config, data folders.
Please let me know
Thanks for your help in advance
Related
Essentially, I'm looking to have a PHP development workflow that needs to be modular, but using a Single Page Application technology.
I understand it is recommended to separate the back-end from the front-end. Develop them separately. But is there a way to group all related code into one module (or folder), meaning all backend code with its own views presentation inside the same folder?
It's like MVC, but the "V" contains fragments of vuejs (or angular) files, which extends from a master file somewhere in your project.
For example
Assume we are building a modular CMS, where you can upload "plugins" (really, PHP modules), extending the CMS' functionality:
-project[root-folder]
----core[folder] # contains all infrastracture code, api routes, master view file, magic, etc.
----modules[folder] # uploadable modules goes here
--------User[folder] # sample module; follows the MVC pattern
------------Controllers[folder] # contains files, e.g. UserController.php
------------Models[folder] # contains User.php
------------views[folder] # where vue components is housed
----------------users/index.php # contains vue code
----------------users/create.php # etc...
----------------users/js/user.js
----------------users/css/user.css
--------Blog[folder] # another module
----index.php # the master view or just the bootstrap file
----gulpfile.js
Then inside the core/ folder, there is a master layout that binds all views together.
Will a folder structure like this be viable?
Obvious problem there is you can't use .vue files (as that would mean, every time you upload a new module, you need to run gulp or re-compile).
Hoping for your feedback. Thanks.
This question will strike a lot of folk as bizarre and twisted. That's the reaction I got when I asked it in the context of .net mvc. I'm with you 100%.
I'm too new to js frontend development (and too ignorant of PHP) to have much advice. It's going to be tricky. Ajax calls to PHP code will need to go to paths below the src directory. But then you want to stop your frontend resources being served from these same paths. Both PHP and gulp will want to use file paths for urls, but at least for Gulp this can be controlled.
I'll follow this with interest. My ambition is to keep in the same folder things you're likely to want to delete together, and for those things to be able to call each other with short, relative paths. The ideal would be to be able to specify the module route independently of the path on disk, and to have this route work for both frontend bundled resources and services. Good luck !
I came across this question whilst searching for an approach for exactly the same problem. I'm building a "platform" rather than an application with a plugin system along the lines of Wordpress. I have the additional issue of the platform itself being a 'multitenancy' environment, too - so any plugins cannot interfere with the core "Dashboard" that holds these things together.
So; posting for a few reasons, two years on...
Did you get anywhere and would you care to share any thoughts?
I came across a quite extensive article for PHP Phalcon that has certainly given me a few ideas. Sharing incase it helps you/others:
https://blog.antsand.com/singlepost/index/5619/How-to-integrate-php-(Phalcon)-and-Vue.js-components
There's a line buried in the series that says "As a rule of thumb. Structure your code, based on the application and NOT on the programming language and frameworks." I'm not sure how wise or not this is, but it certainly gave me something to crack on with.
So right now, I have a module folder a bit like:
/mymodule
/Controller
/Model/
/Template
thing.vue
/Assets
/js
/css
MyModule.php
Assets are handled via a framework route (i.e, /assets/{path:.*} )
Templates are handled via the (PHP) module install script to make sure webpack knows where they live.
Still at proof-of-concept stage but rightly or wrongly, it seems to work well enough!
I am new to both Symfony and Angular and I am trying figure out how the pieces will fit together. I want to user Symfony for my back end and web api. I want to use Angular for the front end desktop like experiences.
I am not sure how the folder structure should be. Do I put my angular javascript/typescript files in folders in the root of the Symfony project and utilize their folder structure. Or do i have two bundles in my src folder. One for the back end/website. Another for the front end? Or should the back end be serving twig templates with angular components inserted?
***** Edit *****
#Tobias Xy Correct me if I'm wrong but that would be creating bundle in the src folder and keeping the files in a resources folders in it correct?
Then i see the following at the bottom:
Frontend-Based Applications
Recently, frontend technologies like AngularJS have become pretty
popular for developing frontend web applications that talk to an API.
If you are developing an application like this, you should use the
tools that are recommended by the technology, such as Bower and
GruntJS. You should develop your frontend application separately from
your Symfony backend (even separating the repositories if you want).
So they are saying make two seperate projects and not use a bundle for the front end?
If so how do you host this? On two different sites?
Symfony is a backend framework, so there is no point in adding a bundle containing only frontend files (css, javascript, etc).
See also Web Assets (Symfony Best Practices)
They say there:
Store your assets in the web/ directory.
Update 23.03.2016
Cerad wrote in the comments: "client-side angularjs and reactjs apps have their own build system just like Symfony does".
This is actually a different topic, but the article I linked to above also says something about that:
Recently, frontend technologies like AngularJS have become pretty popular for developing frontend web applications that talk to an API.
If you are developing an application like this, you should use the tools that are recommended by the technology, such as Bower and GruntJS. You should develop your frontend application separately from your Symfony backend (even separating the repositories if you want).
For Angular 2 there might be differences in the front end build system, but the structure should be similar to the one I use for Angular 1.x.
The folder structure I use to place my front end assets in something we could describe as a three level process. Let's just enumerate the three levels here:
Level 1 - The src/AppBundle/Resources/Private folder
Inside this folder, I place any front end assets that need any kind of processing, like transpile, autoprefix, uglify, etc. This will be the case for most JS, SCSS, LESS or HTML files of your choice. You can define the folder structure you prefer.
Level 2 - The src/AppBundle/Resources/Public folder
This will be the folder that'll contain all assets after processing AND any other asset that didn't need processing, usually images, fonts, etc. This will be the folder structure that will literally be copied over to the web/bundles/app folder in Level 3.
Note: This level is indeed redundant and can be skipped with caution. In my case, I kept it to avoid 'accidents' with the way Symfony wants to install assets by default, which will replace your web/bundles/app folder with the contents of this one. This will be the case if you use any other bundle that installs assets this way, like FOSJsRoutingBundle for example.
Level 3 - The web/bundles/app folder
This is the final public destination of your assets, and the path where you'll reference them in your code. It is just a copy of the src/AppBundle/Resources/Public folder from level 2.
Build system
You will need a front end build system to transpile your files and copy them to the respective folders in level 2 and 3. In my case for Angular 1.x I used Gulp with Node. This means you'll have gulpfile.js file, package.json file and node_modules folder in your project. I didn't care, it worked fine. Just remember to not add node_modules folder to your repo.
In production
Unless you really need to rebuild in production for some reason, you can skip level 1, level 2 and gulp related folders and files like node_modules, gulpfile.js, etc.
You could create the client side as the root document and the server side as an alias location, but careful to not overwrite the alias.
Or you could change the host.
Example 1:
[client] www.example.com/<client_root_dir>
[server] www.example.com/api/<server_root_dir>
or Example 2:
[client] www.example.com/<client_root_dir>
[server] api.example.com/<server_root_dir>
We develop in PHP and HTML/Javascript.
Over time we developed a very big source code library, that contains a couple of hundred PHP and Javascript libraries, that we use for every project. The framework resides its own svn-repository, that we include with an external svn link in each project.
The problem is, that the entire framework itself is about 800MB now.
With only a few projects that we worked on, this wasn't really a problem, but now we have about 30 projects, that all contain a FULL copy of the framework, which takes up a lot of space, and requires constant updating of each copy.
Somehow I would like to have the framework outside the project folders. I've read about referencing other projects in Eclipse, but couldn't really get it to work.
How do you setup the include paths so that each projet 'thinks' that the framework is normally inside the project folder? And can you make a virtual link in an Eclipse project to edit files in the framework just as you would normally do, and get code assist for the libraries too?
One of the main problems is that all our code (and some libraries in the framework itself too) relies on the fact that the framework is in a folder 'framework' inside each project. I'd rather not change all those references to a different path, so maybe I need some .htaccess trick to make this work...
Does anybody else follow the same procedure?
Any advice ?
can you use the "big" project as target platform?
why-create-a-custom-target-platform
If you define it as target platform, the sources are available in your workspace, but they are placed in 1 folder for multiple workspaces. the workspaces will link to the platform, but will not check them out.
I have my main site kansasoutlawwrestling.com which will be using Codeigniter, and then I am also creating a CMS for myself that is a separate entity which will be located at kansasoutlawwrestling.com/kowmanager.
My CMS will use different CSS, javascript, and image files, so I'm wondering if I should just have two different installs of CI. I tried looking at PyroCMS, but there's way too many folders and I was having a problem understanding its file structure. What is the proper set up for this is?
The basic structure of Codeigniter is that you have 2 folders and 1 file in your root folder:
root/application/
root/system/
root/index.php
Now, obviously, you might have many more files and folders in there as well, but these are the basics upon which every Codeigniter app runs.
What do each of these do? To begin with, every page request starts at index.php. This page set's up some configurations and some constants, and then hands over the reigns to Codeigniter.
Where is "Codeigniter" located? That would be the system folder. This folder should never be touched, by you or anyone else. Everything pertaining to your app is stored within the application folder. This includes all your configurations, your controllers, your models, your views, even your library extensions (although you could store other stuff outside this folder, like images/css/js/fonts etc.).
So, the correct way to set up shop would be:
root/application/
root/system/
root/index.php
root/kowmanager/application
root/kowmanager/index.php
But, you have to inform your kowmanager's index.php that the system folder is not located in the same directory. So, within the index.php (inside of kowmanager), at around line 25, you should see this:
$system_path = "system";
Simply change it to:
$system_path = "../system";
and you're done.
Now both your apps (your main site and you CMS) will be sharing the same Codeigniter base. When the time comes to update CI, you'll do that once within the main system folder...
I've done several Codeigniter CMS's and taken both routes:
Integrated (shared application files and assets)
Separate installation (only shared system files, if any)
At first I liked the convenience of the integrated approach: when I needed a custom library or icon file for the front and back end, it was available without duplication. I've since changed my mind.
My opinion now, after 4 years or so of working on these, is that the benefits of having an integrated CMS is short-lived.
90% of the code is in the back end, so you end up with lots of helpers, libraries, etc. that are only used for administration.
Any shared resources that you need to tweak can end up working great on one side, but breaking the other, or being overkill/useless.
Models tend to be bloated for use on the front-end when they are full of code that's only used for the back end.
Shared templates, js, and css files almost never work. The control panel probably doesn't need to work in IE{insert version here}, but your front end should.
It makes updates and upgrades to either end sketchy, unless you know exactly what you need to update and what not to touch, and where you may have made customizations for a particular site's front end that should not be altered.
Auth logic is much easier when your admins and regular users aren't in the same bucket
Separate installations are easier to set up, and they can be "tacked on" to an existing site rather than having to integrate it.
My advice: Go with a separate installation.
If I were you, I would probably not go the separate applications path. If you're sharing things like code that renders a page or logs a user in, you'll be repeating it for both installs. Obviously two separate installs would only require one system folder of which you'd share as nothing changes in system. If it were me, I'd probably just set up a route in your config/routes.php file.
Something like the following (presuming you have a controller called 'kowmanager' inside a folder called 'kowmanager' in your controllers folder):
// This would redirect all calls to kansasoutlawwrestling.com/kowmanager
// to the kowmanager controller.
$route['kowmanager'] = "kowmanager/kowmanager";
// Redirects all kowmanager/method requests to the kowmanager folder
// and a particular controller
$route['kowmanager/(:any)'] = "kowmanager/$1";
// Redirects all kowmanager/method requests to the kowmanager folder and a
// particular controller and method inside controller.
$route['kowmanager/(:any)/(:any)'] = "kowmanager/$1/$2";
Might not be the best option, but it means you won't repeat the same code twice and you've essentially created two applications inside one. There are numerous other ways of doing this including some rewrites in your .htaccess file.
If you want the easier option, go separate installs and be mindful of code repetition. Stick to the DRY (Don't Repeat Yourself) methodology.
When coding in Visual Studio, I can have multiple website projects, and I'm able to switch between them by opening each website project on the local drive. I'm confused at how CodeIgniter handles this operation in Visual Studio. It seems the programming environment is the actual install location. How do I start to code a new website while preserving the code of the previous one? Is there a script to package a project, export the package, and then import it later?
Codeigniter's documentation walks you through managing multiple applications with one installation
As noted in the link above, after structuring your application folder,
Each of your applications will need
its own index.php file which calls the
desired application.
I would like to further explain that after you have duplicated the index.php file you will need to go into your base directories .htaccess file and add a few new rewrite statements to the file.
I have previously taken my application/controllers folder and added subdirectories for each application. The controller routing would have to reflect these changes.