Custom PHP apps, how to get started?
Permalink
Hi folks,
I am brand new to Concrete5 and just implementing my first two websites with it. Wow, am I impressed so far! I have dabbled with some other CMS's but always came away disappointed by either design or programming restrictions. Concrete5 has been a joy to work with so far.
I've got a handle on generating templates and static pages types, all working quite well. But I am confused on how to best approach adding a bunch of custom PHP code operating against its own DB.
In particular, I have a large membership app that I want to bring in. I'd like Concrete5 to manage the UI, but leave everything else to the various PHP programs in the membership app.
I could just stick it all in an iframe, but that has it's own set of issues.
I would much rather see Concrete5 building the "wrapper" around the rest of the code that needs to run. Much of that would have to happen before any HTML output because of redirection requirements in the existing code.
I read about using single pages, but I don't understand completely how those could encapsulate the existing code. Also, there are at least 50 PHP programs that would all need the same treatment, so does that mean 50 single pages?
I don't think custom blocks are the right approach and neither are packages (as far as I can tell).
So, apologies for the long-winded intro... my main question to the group - what's the best way to approach integrating an existing batch of PHP code and DB?
TIA and Cheers!
John Lock
I am brand new to Concrete5 and just implementing my first two websites with it. Wow, am I impressed so far! I have dabbled with some other CMS's but always came away disappointed by either design or programming restrictions. Concrete5 has been a joy to work with so far.
I've got a handle on generating templates and static pages types, all working quite well. But I am confused on how to best approach adding a bunch of custom PHP code operating against its own DB.
In particular, I have a large membership app that I want to bring in. I'd like Concrete5 to manage the UI, but leave everything else to the various PHP programs in the membership app.
I could just stick it all in an iframe, but that has it's own set of issues.
I would much rather see Concrete5 building the "wrapper" around the rest of the code that needs to run. Much of that would have to happen before any HTML output because of redirection requirements in the existing code.
I read about using single pages, but I don't understand completely how those could encapsulate the existing code. Also, there are at least 50 PHP programs that would all need the same treatment, so does that mean 50 single pages?
I don't think custom blocks are the right approach and neither are packages (as far as I can tell).
So, apologies for the long-winded intro... my main question to the group - what's the best way to approach integrating an existing batch of PHP code and DB?
TIA and Cheers!
John Lock
Depending what the code is single_pages could be what you need, they are basically php files that use your template and have access to all of c5's code, if you look in the documentation under Database you can see how to get data from other dbs the "c5 way"
oh, packages are basically just a bunch of things stuck in 1 thing to make it easily installable and uninstallable, it can include single pages, blocks, jobs, models, elements, any number of things, so it could be what you need since it includes basically everything :)
I've built something similar in the past for a sporting club who wanted members to be able to update their membership details and renew their membership from within a C5 site.
The tricky bit with that particular scenario was that the membership database ran inside the client's network on a Windows Server environment, in a .NET app running on MSSQL.
For the C5 side of things, we needed a couple of single pages - one to view/edit the membership details, one to ask about which renewal options and the last to handle actual renewals.
We developed an API using stored procedures on the MSSQL server that allowed us to do each thing we wanted as a single call, providing the required parameters which returned defined datasets. These were nice an easy to wrap in C5 style models, so the fact that the data was coming from something entirely different was invisible to the single pages/controllers and rest of the system.
The major issue that I think you will have is that it sounds like your application is fairly large (50 php programs?) ... I can't stress the importance of developing well structured and separated systems from the initial design, separating all logic, user interface and storage completely. It makes plugging in an API for this sort of thing so much easier!
The tricky bit with that particular scenario was that the membership database ran inside the client's network on a Windows Server environment, in a .NET app running on MSSQL.
For the C5 side of things, we needed a couple of single pages - one to view/edit the membership details, one to ask about which renewal options and the last to handle actual renewals.
We developed an API using stored procedures on the MSSQL server that allowed us to do each thing we wanted as a single call, providing the required parameters which returned defined datasets. These were nice an easy to wrap in C5 style models, so the fact that the data was coming from something entirely different was invisible to the single pages/controllers and rest of the system.
The major issue that I think you will have is that it sounds like your application is fairly large (50 php programs?) ... I can't stress the importance of developing well structured and separated systems from the initial design, separating all logic, user interface and storage completely. It makes plugging in an API for this sort of thing so much easier!
Thanks for the responses so far. The main problem I am faced with is that the custom app already exists. So, no recoding of DB access is going to be possible.
The nature of the custom app is that it employs a redirector at the beginning of each page which checks security and then redirects to the appropriate location. So... this has to happen before any HTML is output.
If I set it up for single pages, I have two options that I understand:
1) Store the code in single_pages and modify the view.php template to include the PHP redirector code from the custom app, so it can do its thing before any HTML gets sent. But what does this mean to the rest of C5? If view.php were modified so specifically, will something else cease to work?
2) Store a custom view template in the theme for each one of the custom single pages. This avoids modifying the default view.php and gives each page its own template, which are all basically identical. Sounds clumsy, but it could work.
Am I missing other alternatives?
The nature of the custom app is that it employs a redirector at the beginning of each page which checks security and then redirects to the appropriate location. So... this has to happen before any HTML is output.
If I set it up for single pages, I have two options that I understand:
1) Store the code in single_pages and modify the view.php template to include the PHP redirector code from the custom app, so it can do its thing before any HTML gets sent. But what does this mean to the rest of C5? If view.php were modified so specifically, will something else cease to work?
2) Store a custom view template in the theme for each one of the custom single pages. This avoids modifying the default view.php and gives each page its own template, which are all basically identical. Sounds clumsy, but it could work.
Am I missing other alternatives?
singlepages and views are separate, singlepages use views, the view is basically the theme where the singlepage is the content, a singlepage would do exactly what you need.
