I'm currently working on a PHP project using CodeIgniter as my framework. I took a look at a few templating systems I could probably use - Strogen's Templating System (currently used in PyroCMS - if I'm not wrong), Twig, Smarty etc.
But I have decided to go on my own to build one from scratch. Since I have experience dealing with Wordpress templates, I was thinking of creating something similar.
To give you a run down of how wordpress themes work - Wordpress has a set of functions (Theme functions) that help gather data. I was wondering if following the same would be a good idea for my project as well?
If I did create such template functions which I would be calling within my views, would it work against the MVC principles? And would it affect the performance in any way?
Well, with MVC, models do the db interactions, views display the data, and controllers are the go-between. If you created your "template functions" in the controllers, I suppose you would be complying with MVC. If you wanted to say, create a library or helpers to do the gathering of/manipulation of data, you would not be complying with MVC convention. AFAIK, it's a matter of preference which way you choose. As far as performance, you could use profiling to test which is better.
However, if your aim is to build a templating system for CI that is similar to WP just because you are familiar with the way WP templating works, I'd proffer that it would likely take you substantially less time to learn a new one than build your own. I'd also imagine it would take much less time to learn the new one than it did to learn the WP one.
Also, I think pyro uses a combination of Phil's templating and smarty, but not positive. Phil has a templating system available for CI here: https://github.com/philsturgeon/codeigniter-template May be worth checking out.
cheers.
Related
We're planning a new intranet for our organization. Some part is like a CMS, and there are some custom-made applications.
The Symfony2 CMF distribution looks fine for building the CMS part of the intranet, but other parts like Doctrine, "normal" SQL databases, etc, looks better for the custom-made applications for the intranet.
Because I need common authorization and authentication system for this intranet (against an Active Directory), I supose that I'll get better results building all in only on app. So, can I mix a CMF application with a normal application, and both use the same database (an Oracle DB)?
Yes you can easily mix the CMF with other Bundles. For example the routing allows using both routes from the CMF as well as "static" routes defined in yml files. Also you can easily also add the ORM next to PHPCR ODM. If you use Doctrine DBAL for storage in PHPCR, you can even reuse the same connection configuration with the ORM etc.
In brief yes it is, and I do this in my own Symfony2 project. I combine both SF-SE and SF-CMF bundles.
In fact, with Symfony2 it's very simple (this is just a matter of choosing the most suitable Bundles; SF is a very decoupled framework, which is why I don't plan to migrate to any other solution for the moment), but I'd like to share some of my experience with doing that. Actually the one most important question to think through to make a decision about how to combine both "worlds" is this:
Composer.
After some inquries I found out that since Symfony CMF is (in a way) based on Symfony SE, and not vice versa, it's better to start with the latter, as it contains the most core features (though I did it also in the opposite way, rather not recommended). So just take a SF-SE's composer.json, take a look at bundles from there you need, and then take a look at differences within SF-CMF's composer.json. You should end up with the most suitable set of bundles.
The basic features from these bundles to look-up for are:
MODEL - Doctrine ORM, PHPCR-ODM, or both - if still not sure, don't hesitate to ask a comment, I'll share here my experience furthere.
ROUTING - the primary question here is how flexible routing do you actually need? If not sure, I'd go with standard SF Router, and then possibly replace it e.g. when still on a dev stage.
OUT-OF-THE-BOX CMS FUNCTIONALITY - bundles such as CreateBundle, MenuBundle or MediaBundle may help you building surprisingly fast, but not quite flexible soltions. In general, I ended up without using most of them, and if using, then I mainly take some Interfaces I do implement in my own Bundles (to ensure future compatibility with possible other bundles to be potentially used).
Besides of these above, I created a number of Bridge Design Pattern and Provider Design Pattern solutions to make some bundles working together, to adjust their functionalities, or simply to decouple things.
In programming almost everything is possible. But think about restrictions delivered with CMF (routing for eg.).
Maybe you should consider Standard Symfony with Sonata? I think CMS pages it's only small part of your system and implementation it in standard symfony will take smallest part (and cost) of whole project.
Going forward a company I'm working with atm would like to stop with various frameworks/cms systems and go forward with just one for all future clients.
To that end, I've prepped a list of options and it's been whittled down to Pimcore and PyroCMS.
I'm a CI developer so clearly Pyro wins for me, but the guys who will be developing custom modules are more comfy in Zend. I found this: What are the (dis)advantages of pimcore? and found it quite enlightening.
So I'm curious to know thoughts on the two systems based on the following criteria:
Reskinning potential (front end themes etc).
Custom module ease. Building modules is really easy in Pyro and intuitive (if you know CI).. is Pimcore as easy for a Zend guru? Also, just buying/downloading existing modules, which is more prolific?
Multi site usage (can one install allow an admin user from site A to only see site A content?)
The docs and marketing blurb is great for both sites, but any hands on experience here would be useful.
I'm thinking that we could also just use the Zend library within Pyro (as you can do with CI on its own). Anyone reckon that'll be a headache to use?
PyroCMS developer dropping by.
PyroCMS can handle all of the 3 requirements you have requested. Now, CI and Zend users often have arguments over which framework is better, who is the best, bla bla bla, but it can easily be said that CI is the easiest to learn.
If you have some Zend developers, while they might prefer to use a Zend-based CMS that really should not be a selling point on the application itself. These days people put so much focus on which framework they prefer they seem to ignore everything else.
So, evaluate the two products on their own merits.
PyroCMS can handle multi-site and the frontend (and backend!) can easily be reskinned using just HTML and some basic tags - much like Smarty-ish.
And yes, you can use Zend components in your CodeIgniter/PyroCMS application, so that shouldn't be something to worry about.
We have used Zend in a few of our custom PyroCMS modules. Definitely go with PyroCMS so you get the flexibility of both frameworks if you desire. PyroCMS 2.1 just came out and it just keeps getting better.
Is there any case that creating your own CMS for a specialized website more advantageous than using a prebuilt CMS such as dotnetnuke or umbraco? Can anyone site a project when they had to create a custom CMS and not used a prebuilt CMS? Where to draw the line from using a prebuilt CMS to a customize CMS? Or is using prebuilt CMS always more advantageous than building your own CMS in any type of content driven website?
With the quality and variety of current open source offerings, I would say it's almost never a good idea to start from scratch. It really comes down to requirements and features. There's a huge variety in the features and user experience of different systems out there. You really need to figure out the priorities (performance vs. ease of use vs. flexibility vs. extensibility vs. SEO) to choose the right one.
I generally go with DotNetNuke with an assortment of custom modules to enhance aspects of its CMS and SEO capabilities. There's just not much you can't do with DNN once you really get to know it. But if performance is your highest priority, another option might be preferred.
I think it depends what the overall goal of the project is. If you are building a marketing website or your project can be easily accomplished with a pre-built CMS then you should certainly start there and build modules or customize a little if needed.
However, if you are building a web application that's core functionality is not just content, page management you have to consider going a custom route. Pintrest, Facebook, Flickr, etc. would definitely not start with a pre-fab CMS.
The Onion started with Drupal at one point but realized their needs were so custom that they ended up doing it all in Python/Django. Plus, with frameworks like Python/Django and Ruby on Rails if you are building web apps you can easily create the CMS features you need.
We do a lot of DotNetNuke, some Drupal and all of our custom web apps we are doing with Ruby on Rails. Once you have the requirements and goals of the project you have to look at your tools and see what is the best for the job. And sometimes it's making your own tools :]
if you move for a prebuilt CMS, you have to use their available functions and do improve whatever your features. but if you go fro a new custom CMS, you are free to customized to the maximum.
What are your requirements? If the majority of your requirements (65% +) are CMS related requirements, than I would strongly recommend looking into existing CMS solutions (opensource or commercial).
On other hand, if your CMS requirements are about 35% of your total requirements, then I would consider implementing in-house, fairly light-weight CMS.
Be aware, CMS sounds like an interesting and easy to tackle task, but when it comes to it, it is likely to be the most complicated project that you have ever worked on, mainly due to its extensibility, security and efficiency related requirements.
It all depends on what the requirements are for the project.
Should I avoid using a CMS if I want to be able to quickly make good sites with more features/options to customize than Wordpress?
I want to become a better webdeveloper and able to quickly make good, fast, secure websites with lots of functionality without being limited so as I'd be with Wordpress. I don't see writing lots of plug-ins to reach the same functionality as a nice solution for doing my own programming.
I have written a few games, quizzes and other scripts I'd like to be able to recycle or easily adapt to work with the CMS.
I currently have a multi-lingual website that works with a /nl/ and /en/ part, that has a few self-written games I wrote in PHP.
CakePHP has a very good CMS called Croogo. It's still quite a young project (still in beta and being actively developed), but the great thing about it is that its a Cake app so it's coded to the well-documented Cake standards.
Whereas customizing/extending Wordpress, Joomla, Drupal et al would mean you'd have to invest a huge amount of time learning about their respective frameworks, all for the sake of one part of any given website (the CMS), if you learn CakePHP, you're learning a much more advanced and flexible framework that can pretty much be used to do anything well beyond the confines of CMSes.
If you learn Cake (or if you already know Cake) you'll find that you already understand Croogo without having to invest much additional time at all. Code you write in Cake can easily be packaged to be a Croogo plugin and even if Croogo doesn't stay around for the long term (I hope it will!), it wouldn't be difficult to re-factor all the plugins you've written to work in any other Cake-based CMS that comes along in the future, or even your own Cake apps.
Croogo is pretty basic, but quite powerful. It has a Wordpress-like feel to it, it supports nice URLs via an amazing reverse-routing system, the /en/ /nl/ language thing you mentioned works out of the box and it's very easy to get any of the huge array of Cake components and plugins working in harmony with the CMS through the use of hooks.
I'm currently working on a project using joomla and there are a ton of custom features that I need to implement. I usually have to create a plugin or module in that case. It's a pain. I'd much prefer doing most of this from scratch instead of hacking at the code. If I had a choice, I would not use a CMS. I hate them.
I think ultimately it's about long term support. When you build a custom CMS in cake or another framework it is much easier and faster for you to customize and build the way you wan too. This works great if this is a project you are planning on supporting (by this I mean bug/user support for when you unleash this CMS on non devs). This can become a headache pretty fast when things need updates and clients are looking for fixes and changes. It's completely manageable, just more of a headache then something with community support.
That being said, if you are comfortable in wordpress the amount of support that exists in that community is huge. So often times you can leave the project knowing updates for the CMS and plugins will come in at a regular speed.
TLDR So if it's a project you know you will be supporting long term (or people with the same comfort and skill level as you) then I would say build it your self for ease of build and customization. If this is a one off or something you plan on handing off to a client with little to no support, building inside of a community supported platform is best.
I really comes down to priorities, if you what to build a site really fast a CSM is hard to beat, but you do not have the same control over the core as you do when you wright it from scratch.
But you can do most any thing with plugins/modules so the control is there if you are willing to work for it. If you wright it your self you will be the only set of eyes most of the time so it will in most cases be slower to implement new standers and security fix's (because you will need to find them first) but with a CMS you will have many people working to make it better and safe at the same time.
If you want to be well rounded I think youe need to be able to do both, you can't control what the customer wants to use some times.
You can make site very quickly with a CMS like Joomla but the problem is even having over 7000 extensions sometimes for your particular purpose you don't find an extension and developing an extension can be real tough. it requires a comprehensive knowledge of Framework. If all you need to do is manage content CMS is the best choice. If it is like a web app and require more interactions go for some framework which provide the basic skeleton of your app. e.g. for CRUD operation many frameworks provide scaffolding feature and make this thing a piece of cake. CakePHP, CodeIgniter, Kohana are some of the best PHP frameworks you can use.
Using Chinese Cms DedeCms or phpcms And developer it more easily !
I like PHPCMS, it works with nginx, fasctcgi, mysql on linux or windows.
I use it to make portal site or enterprise sites group. The multi-site architecture and PHPSSO works well. Template engine is also strong enough.
take a look at big mysite: xinm123.com
Most important thing: it's open source.
I would like to ask those who are experienced with building a website with Drupal. I got a job like this, but I'm more interested in programming. I got also another job offer and cannot decide!!
How often do I get to programming/changing code in Drupal, when building a site in it? Isn't it just about clicking around and downloading modules?
the other job is different but i didn't want to write long descriptions here. This job with drupal got all the positives, but im afraid that its less programming, more clicking and im trying to learn more programming. the other job is classic php programming with company internal framework.
thanks guys
I work in a company where I mostly do Drupal development. Now it's hard to say anything concrete about your job offer, since we don't really know the company etc. There's not really a reason why doing development with Drupal should be any less coding than doing development with some other PHP framework.
You get a lot for free with Drupal, the whole CMS part, all the modules on drupal.org, and yes there will be some AI configuration, but it's usually not that much. All the configuration part of a Drupal and modules is pretty easy if you know what you're doing. For me I spend around 5% of my time for a project doing configuration, making views (a drupal module you can use to create displays) etc, the rest of my time, I use hacking away in my code editor.
As a drupal developer, you mainly do two things.
Write code to add functionality
Write code to alter existing functionality.
Drupal is run is procedural, so there's not much classic OO, instead you write code that gets executed when something happens. Fx a user logs in, then you get a chance to modify the user, do some things like counting how many times the user has logged in.
An important part of Drupal is also presentation. In Drupal we call this theming. Theming is also very code heavy. Drupal is very flexible, so you can overwrite functions used to generate the markup in your theme. These are classic PHP functions. Then there is the whole css, html js part as well.
If you have the chance to do Drupal development, I think you should take it. There is a massive demand for good Drupal developers, that know how Drupal work, and how to use the APIs. It will be something you can use to find your next good job. Knowing some random in house PHP framework, will probably not help you as much in terms of finding your next job.
It's going to depend on how much you want to customize Drupal. You'll typically get to spend some time altering code to change the layout or whatever other UI-related requirements your employer/client would like.
As far as altering the core of Drupal, you wouldn't want to do that anyway or you could run into trouble when a new version becomes available and you want to upgrade. Any custom coding would instead be done in the form of writing Drupal modules or plug-ins.
Comparing your two brief job descriptions, the "classic php programming" option sounds more like what you want to do. There simply wouldn't be a comparison between doing development in Drupal vs. doing development on some company's internal framework, but either way you would get some experience.
Don't let this answer guide your decision on the offers. Pick the one that feels right and works best with your lifestyle. You can always do your own research and development outside of work if you wish to gain experience or knowledge.
It heavily depends on the project. I work as a professional Drupal developer for 2 years.
Normally making a Drupal site consits the following steps:
the site builder gets the spec
the site builder makes a research what modules to use
the themer makes a wireframe
client accepts the wireframe
the designer makes the actual design
the themer starts implementing the design
the site builder starts installing and configuring the modules
if there are problems which can't be solved with the available modules, then the developer gets a specification
the site builder finishes site functionality and applies the theme
testing
deploying
As you can see, your job will be depend on which role do you work. If you apply for a site builder, then you don't have to code much. If you get hired as a developer, you will most likely end up writing bigger or smaller modules for different projects (this is what I do most of the time). At smaller companies, the site builder and the developer (sometimes even the themer) are often the same person.
However if you want to make sure that you will write code all day (and you don't know what roles will you fulfill at the Drupal company), I rather recommend the second job.