Natetronn

I don't recall saying front-end themes could come from just adding a template engine. In fact, my last post (see next quote) for the most part tried to move away from the original title of this topic to what is was meant to be about from the start which was finding ways to make things easier on users. The template engine was an idea though, yes, off topic from Ryan's original post as I remember it; I see that now. I agree with this and mentioned something to that extent in my last post as well. With that said, I guess I don't know what the original topic from Ryan was about anymore to be honest because PW isn't really setup to be easier than WP rather, by design, to allow freedom to model data among other things like you said. I'm going to have to re-read that topic again I guess. @Joss I think Drupal does something similar with their profiles in regards to having a set of profiles which are module based though, also theme based. That of course isn't like WP and is a one time install just like PW would be as I remember it. It is however a good idea to allow people to quickly setup common sections of a site like a blog to help keep things DRY. So, site profiles which aren't necessarily theme based that could be installed at any point one needed them would be nice. Client needs a blog now, you just grab the "blog module/s based profile" and go. I seem to remember seeing a module which would help for quickly setting things like this up though, I don't remember for sure. EE has something similiar which may never see the light of day but, you can still check it out here.

Let's not forget the original topic of this post way back when I posted it which was finding a way to make using PW themes easier than WP. With WP most people who don't know how to use a lot of PHP end up buying a theme as is or maybe buying a theme and re-skinning it directly (via css etc.) or even using a child theme. And we all know there are a bazzillion themes out there to choose from. Allot of them with built in admin panels for changing almost everything in a design from colors to fonts to logos etc. Then little by little when they out grow re-skinning and feel more comfortable with things they start playing with PHP and WP's "loop" among other things. Bringing up template engines was only one idea to help make things easier for people though, I'm sure there are many other ideas as well. With that said, it's probably a much bigger issue than just using a template engine or not. PW, as it sits now anyway, isn't really setup for themes as much as it is for building sites from scratch. This is similar to other systems, like EE for example, as you can't install themes over themes per se. I think that's the case with PW as well though, I could be wrong so, please correct me if I am. The flexibility, power and freedom CMS like this provide takes work to use & to learn and often times when you are just starting out its just easier to, well, not work/learn. Anyway, maybe that was why the post was started in the first place, I don't know. For me, offering a template engine is kind of a mid ground in a sense, as it allows people with less php experience to "feel" more comfortable. I do get the arguments about having to learn one thing so, might as well learn PHP from the start, however, that doesn't address the issue at hand (or at least the original topic from the quote.) By the way, there are also other reasons which no one has mentioned which make using a template engine a possible good option like separation between logic and view (or what ever it's called.) Allot of other languages, frameworks actually, offer this pretty much by default (although by choice.) Not saying PW needs to do that rather, I'm just saying. Ultimately, I guess we never really answered the question from the quote above and I'm curious (as I don't know myself) how to make working with and installing PW themes as easy (easier) than WP? (and let's not forget about one click upgrades for both core and modules!)

You read my mind! I've actually set something up like that with a few WP clients which I have via WP Multi Config. I actually got the idea from EE Master Config which I use on every EE build I do now days. I was thinking I will try to get something like this setup for PW and why I started this topic Thanks again.

Thanks for the replies! @ryan, I did look that over actually (don't remember how I found it as it is hidden, you're right.) I'm not worried so much about multi-site per se rather multi environment so I can dev on my local machine and use things like Git (version control) and Beanstalk to deploy up to dev/stage/live servers. I think the file I mentioned will actually allow this though, I haven't tested it yet and currently don't have free time to try it though, will soon. Thanks!

I noticed there is a file named index.config.php in /wire which is the "ProcessWire multi-domain configuration file" and I'm wondering if this is for multiple PW sites similar to WP Multisite or EE MSM or am I confusing it with Multi Environment setups. For example if I wanted to have a local, dev, staging, live/production multi environment setup would this be the file to use? Where all the domains, paths, db settings would most likely different from enviro to enviro? It looks like this is in fact for setting up multi-environments now that I read and understand what's taking place. The fact that it's called mulit domain is throwing me off a little, however and why I wanted to double check I guess. Is there anything to worry about with these types of setups in regards to paths or does PW handle all that for us and we just need to worry about setting up things per the instructions in the file? Any gotchas in other words?

My mistake, it was late, it works now

Hey Tyssen! I updated the module for you though, not sure how to hand it over other than via a gist: https://gist.github.com/4554543 The file I updated was in wire > modules > Inputfield > InputfieldTextarea.module Note: I know how to make a pull requests though, not sure which branch to use (Ryan?) plus, I'm just getting use to looking at PW code so maybe it should be looked over by a PW professional first Also note: I wonder where this should go for the time being. For example I wonder if this will work in the site/module directory since it's now custom. An update to PW of course would overwrite the changes made in the wire/modules/Inputfield version. Anyone care to explain the proper way to handle custom or modified core modules please?

I think I can agree with this. And most hardcore or long time EE users seem to be taking this approach (or see quote below.) They aren't throwing in the towel though, are considering alternatives for various projects. PW isn't alone in this as I've mentioned I think. Shoot, some might be moving towards building apps via Laravel; I don't know! I will say that PHP in templates will scare off quite a few right from the start; which is fine either way (we don't need to have this discussion again of course.) Now wouldn't that be oh so nice! I think that will be the name of my second boat

Most of your points which make PW great are very similar to what make ExpressionEngine great. That's why I'm even here. It's about freedom to build a system that meets your client/project needs. Custom fields is something that PW and EE both do very well where as many other systems do not. WP is trying with custom post types and ACF but, they're not there yet (oops, there I go again!) at least not by default and Drupal has CCK but it's a PITA IMO. As far as there being a ton of add-ons, well, EE isn't like WP/Drupal/Joomla. It doesn't have a million add-ons. It only has about 1500 add-ons (according to Devot-ee at least.) Granted there are 4 or so commerce add-ons but, they all have their place and some projects call for one over the other. Sometimes is just personal taste. You really have to spend a few months with it to know what I mean. I guess that could be said for most CMS, however. EE has almost zero themes by the way. Something I think which has helped WP and Joomla grow so large as communities. The changes with EL are why people are considering other options. The CMS and eco system itself isn't the issue as far as I can tell. At least it wasn't. Most don't even mind paying for it and for add-ons by the way. This could change of course in the future but, EE the CMS and EE the eco system are currently in a great state from all I can tell. EL has done what they feel is the best for their future and although, it was pushed out very quickly and without any warning they, I'm sure, are doing the best they can from their vantage point. Let's see what this year holds. I'm glad to see some of the todos like tutorials and documentation/examples etc. You're not getting ahead of yourself which is good. Curious to see what Ryan has to say as well. Thanks for the discussion by the way, this has turned out to be a much better thread, don't you think