Hi all, I am new to ExpressionEngine and would appreciate if someone can answer a few basic questions.
Same goes for a few other PHP libraries, like FPDF, Symphony Mailer etc.
In the docs I see that the database section is under legacy reference? Is there a newer way of doing DB stuff?
It’s great that members module is available right out of the box, but I can’t find anything about, for example, how to register with just an email and having password auto generated.
Basically I want to know is EE nice enough to let me use other PHP libraries for various tasks, or I need to follow some rules to use them?
Thx
Yes, you can use your existing PHP code. Enable PHP on your EE template on which you need PHP. Consider the security risks of doing so, this is fine if you don’t allow a member to edit that template, otherwise if they can add PHP code they take over your EE installation.
You can interact with a database using the Query module (no PHP required in that template):
https://docs.expressionengine.com/latest/add-ons/query.html
But it’s only for read queries.
Legacy, means you can still use them until they come up with a replacement. You can interact with the database using:
https://docs.expressionengine.com/latest/development/legacy/database/active-record.html
About the members, you can either enable the legacy templates which already have a build registration, login, profile pages:
https://docs.expressionengine.com/latest/member/profile-templates.html
Or create your own registration in a template with the proper tags (this is the suggested new method, as you probably want to match your website look and brand):
https://docs.expressionengine.com/latest/member/registration.html
Using third party frameworks libraries might a bit tricky, you probably want them to keep them in your own external PHP files (you can still use them in your EE templates by including them if required) but you should really consider why using them instead of using native functions since EE is more or less its own framework and already has mailing libraries, validation, etc.
There is already a PayPal module here:
https://docs.expressionengine.com/latest/add-ons/simple-commerce/index.html
No Stripe one, but there are external commercial add-ons. Or you can use your own existing code.
Keep in mind… as he stated above, you CAN run PHP and PHP libraries in the pages in EE, but generally it is recommended against doing so just due to security risks. I have found that If I can write simple PHP and I am already writing them into a page, then it is easy enough to write those into a custom Plugin and then just pass EE tags for them into my templates and leave PHP for the pages turned off.
The legacy framework is rock-solid … “Legacy” doesn’t mean it is going away anytime soon & it is based on Codeigniter 3 (or maybe 2, I don’t remember) which is very well documented…
There is a plugin for PDFs available for EE - it was just taken over by an active member so it should see regular updates and be top-notch … as well as work within the EE Templating system …
I second what Russ said; don’t put PHP in templates. It’s gross; business logic has NO business (teehee) being in a template, and quickly becomes a maintenance and security nightmare.
Creating an Add-on is simple; there’s even a tool included to do all the boilerplate for you.
php eecli.php make:addon
it’ll walk you through the rest, wizard style.
Thanks for taking the time to reply…x3!
I’ll leave using any PHP code inside template as a last resort.
Hopefully creating add-ons to wrap my code is easy as you guys say it is. I agree that using a CMS/CMF and let’s say send emails manually defeats the purpose of using it in the first place, but I just wanted to be sure that I can take advantage of EE for some things and not worry if my custom code will be an issue.
Your answers are exactly what I wanted to hear, I’ll report my progress here once I get my hands dirty.
I agree with add-on approach, and it’s very common for frameworks to separate template tags (twig, smarty) etc. from PHP code, but there is a reason they still allow PHP and so does EE. All of them actually allow for PHP if a setting is enabled. And lets not forget that PHP was actually a templating language as well, to be used in HTML with print and echo tags. Some might not be aware of that, but initially PHP was exactly designed for that purpose, as a template programming language for websites. Today we have Twig and others that replaced it. EE having its own of course with EE variables.
But….
If you need 1 single PHP line on a file, it might not make sense to create a complete add-on for that. And let’s be realistic, while EE is great for content management, there are some things you can’t do in a simple way, but it’s very easy with PHP. Now imagine some calculations or operations, and you have hundreds of them that are different. Are you going to create 100 add-ons that contain 1 PHP line? I can think of many things that are tiny operations that EE can’t do out of the box, in particular with regex validation that does not work well and in the end you have to rely on PHP.
If you are going to re-use your code over and over again, absolutely, the add-on makes sense. Or maybe you can create one huge add-on that outputs all your code, but initially it’s easier for newbies or coming from other frameworks or CMS’s and just know PHP to get started right away. We can’t expect someone new to EE to be creating add-ons from day one when all they want is migrate their existing working PHP code.
Eventually, of course, the better approach is to move your PHP code to an add-on and keep it away from the templates. But technically you are just injecting the PHP using EE into the template as well.
Taking away the management issue, since mixing PHP with styling is as said not clean and hard to maintain, PHP is safe to run in templates if you are not giving those members access to the control panel or permissions to edit those templates. Example, a page that is only executed on the front end or back end which nobody except the administrations can edit or manage, and other users are just able to render like any other normal PHP page.
He mentioned Stripe API as an example, which makes sense as you would not give members access to edit your API PHP source code but just execute the requests from EE possible passing site or member variables that are required.
I agree with add-on approach, and it’s very common for frameworks to separate template tags (twig, smarty) etc. from PHP code, but there is a reason they still allow PHP and so does EE. All of them actually allow for PHP if a setting is enabled. And lets not forget that PHP was actually a templating language as well, to be used in HTML with print and echo tags. Some might not be aware of that, but initially PHP was exactly designed for that purpose, as a template programming language for websites. Today we have Twig and others that replaced it. EE having its own of course with EE variables.
But….
If you need 1 single PHP line on a file, it might not make sense to create a complete add-on for that. And let’s be realistic, while EE is great for content management, there are some things you can’t do in a simple way, but it’s very easy with PHP. Now imagine some calculations or operations, and you have hundreds of them that are different. Are you going to create 100 add-ons that contain 1 PHP line? I can think of many things that are tiny operations that EE can’t do out of the box, in particular with regex validation that does not work well and in the end you have to rely on PHP.
If you are going to re-use your code over and over again, absolutely, the add-on makes sense. Or maybe you can create one huge add-on that outputs all your code, but initially it’s easier for newbies or coming from other frameworks or CMS’s and just know PHP to get started right away. We can’t expect someone new to EE to be creating add-ons from day one when all they want is migrate their existing working PHP code.
Eventually, of course, the better approach is to move your PHP code to an add-on and keep it away from the templates. But technically you are just injecting the PHP using EE into the template as well.
Taking away the management issue, since mixing PHP with styling is as said not clean and hard to maintain, PHP is safe to run in templates if you are not giving those members access to the control panel or permissions to edit those templates. Example, a page that is only executed on the front end or back end which nobody except the administrations can edit or manage, and other users are just able to render like any other normal PHP page.
He mentioned Stripe API as an example, which makes sense as you would not give members access to edit your API PHP source code but just execute the requests from EE possible passing site or member variables that are required.
I’m bored, had a few beers, had a good week; sure, I’ll bite.
I always looked at settings like those in the scenario of:
“Are you sure you wanna put the gun to you head?” - system
“Yes” - dev
“No, but like, are you REALLY sure you wanna put this gun to your head?!” - system
“Yes” - dev
“Well, I mean, ok… but you have to enable a specific setting to make it explicit this was YOUR choice and our hands are clean” - system
Also, separation of concern has been around as a concept for, like, all… the years. It even predates MVC as a concept. You don’t mix UI with business functionality because:
> it locks the client into the UI by adding increased costs down the line.
If anyone hasn’t done it, it’s incredibly time consuming and complicated (read: expensive) to dig business rules out procedural code and global variables. And, in this case, where there’s an easy out to solve problems AND not saddle clients with burden, well, I would just consider tomorrow, when it comes to any implementation.
@vw000 In my case, I only use PHP for two things:
Dynamic pricing which outputs different prices based on what ipstack’s API returns. This gets output immediately in the php that renders the page(that page is pure HTML sans the few echoes to display the price.) I can use JS to fetch prices and render them, not a big deal because server side validation is done before actually trying to process the payment.
Everything else PHP related falls in the following category - PHP files with business logic to validate coupons/vouchers, Stripe/Paypal payments, save orders to the DB, generate PDF’s, send emails etc.
I only talk to those files via Fetch API. If not for dynamic pricing, I don’t even need to save web pages as .php, they can be plain .html files.
If my logic is right(I have a designer brain fyi), I don’t need to include PHP inside EE template files at all. Let’s say that I manage to wrap code that validates coupons as an add-on, can I talk to the add-on via Fetch and get a response?
I am much more comfortable with JSON and parsing responses than actually doing stuff with PHP only. For these reasons I liked EE, it doesn’t impose any rules when it comes to templating/layout, I can leave markup as it is and use tags for dynamic stuff.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.