Craig

I think Pete was right actually - the way I see it, the API, coupled with templates and fields, essentially, is your ORM An ORM is just an abstraction on top of a database which makes the data easy to work with. Your database contains your tables, columns and rows of data. In ProcessWire, your rows are pages; your columns are fields, and your tables are templates (roughly!). So to interact with those, you use the API. Relational data can be handled by using the Page reference fieldtype, for example. Having said that, if you have a desperate need to use something other than ProcessWire to manage some data, it is just PHP. Find an ORM you like, include() it, and start using it within your site as and when you need to.

Those two projects sound like great ideas to get stuck in to with ProcessWire. I think most people here would recommend using the development version now, and just keep updating as you go along. It's fairly stable right now, and updates are very simple to do (just replace the /wire/ directory, usually). I don't think there's a date scheduled for a 2.4 release - it will be ready when it's ready I started a website using the dev branch in August, and it's almost ready to launch. I've updated the work-in-progress site several times during development and it hasn't been a problem. So I would say go for it

I'm not quite sure what you mean by "present it streamlined in forms", but I think the gist of your request is about getting some data into ProcessWire in order to sort/display it based on a search/filter. The CMS Critic case study post has some great examples of importing from a WordPress site using the ProcessWire API, so it'd be a great example to look at to see how it's done. Once the data is in the site as pages, you are good to go.

Wow. That's a terrific-looking site. Good work

Yes, this is possible There are several options you could look at. The first one is if you feel comfortable tackling this with some code, and you don't need to do this in the control panel interface. There's a module called Form Template Processor. The second option is to use the brilliant Form Builder module, which (amongst other things): "Saves entries to a database, email, ProcessWire page, 3rd party service, auto-responder, or any combination of these". Another option would not be to use any modules. If you do it this way, you use your page templates to manually create the form and input fields (using plain HTML, or ProcessWire's API to load Inputfields) as well as processing the data upon submission and then creating the resulting page.

Hi cam503. There are several ways this could be done, and there probably won't be a right or wrong answer. I probably won't be able to give you the best answer, because I don't know how your site is structured, but I'll try to point you in the right direction In your example above, it looks like the $helpers->renderPage() function handles the final output of the page based on the data you set above. You could extend that to say: $page->javascript = '<script>var something = 1;</script>'; You could then access that in the same way you do for the "layout" property. Another way might be to add a new field to your page template(s) where the javascript could be entered in the control panel, and you could easily access this from the $page variable within the template. Another way could involve javascript files named after the page's "name" field value, and you could then use this as a basis for loading a script via <script src="..."> after a quick file_exists() check.

I am not a lawyer, but my simple understanding is that the clauses of GPLv2 are triggered only when distributing the covered work. You can make any changes you like to the code, including removing the copyright line from any viewable interface, so as long as you do not distribute it. I do not think that allowing your clients access to the control panel can be classed as distribution, in the context of the GPLv2. However, if you were to make your modified version available for download, or give them to somebody else, it would then have to satisfy all of the clauses within the GPLv2 where appropriate - which would mean the copyright notice should stay, and that all the modifications are also under GPLv2, same conditions apply etc. This distinction is important. The AGPL is similar to the GPL, but "distribution" also extends to the modified work being "performed" - e.g. accessed over a network. IMO, the GPLv2 is vague and confusing, and open to (mis)interpretation. A lot of people's complaints about v2 was solved with v3 (and in other licenses), but with those, come other conditions that authors may or may not want.

I would add a JS object to the page in your <head> tag, from your template file. For example: <script type="text/javascript"> var user = {}; user.lang = "<?php echo $user->language->title ?>"; </script> Here, I have specified that user is an empty object, and setting the "lang" property of it to the value from PHP $user->language->title. This way also allows you to add other properties to this should you wish to use more user attributes in the future. You can then access it from javascript as any other object/variable: if (user.lang == "no") { // one thing } else { // another }

Yes, the right one was Arial, and the left one was Arimo with SVG at the top of the font "src" stack. I've had a look at the Google Fonts page, and the result is shown in the attached image. It renders clearly, but again - it's the bold 'e' at that size that is the ugly duckling. For comparison, I added Open Sans.

Is your CodeIgniter app actually a Fuel CMS install?

If I'd have said Comic Sans, then I would agree with the last part I do see your point of view, and I am not a designer per-se. But I often take a more functional approach, rather than purely aesthetics. The Arial, Helvetica, sans-serif font stack works, and has done for a long time and in many designs and situations. Its use case here - in the control panel - (in my opinion) is not one of the situations that demands or calls for a webfont just because.

One of the issues I didn't notice before was that your controller was called "Processwire" - the CI class name conflicts with ProcessWire's - so I would advise using an alternative name for your CI class. I also think the include path is throwing things out a bit. My test looks something like this: <?php if ( ! defined('BASEPATH')) exit('No direct script access allowed'); require_once(realpath(FCPATH . '../../test/processwire') . '/index.php'); class Welcome extends CI_Controller { public function index() { $this->load->view('welcome_message'); echo wire('pages')->get('/')->title; } } /* End of file welcome.php */ /* Location: ./application/controllers/welcome.php */ Can you make changes to yours to reflect the above? FCPATH is the location of CI's index.php; and realpath() will convert the whole "relative" path to the correct full filesystem path, and then we just add PW's index.php on the end of that.

Using the latest dev branch, it still renders badly on Windows in Chrome and FF (but FF being the better of the two), particularly the bold sections. If the CSS is changed so that the SVG file is referenced before the others (I think this was mentioned/linked to earlier in this thread) then Chrome handles it a bit better; but with the side effect of the text not quite as clear as it should be. See the screenshot attached. On the left is the "Edit" page with the SVG font reference at the top in the CSS, and on the right is the same page, but with all of the webfont references removed from the top of the CSS - falling back to the default system fonts. In my opinion, there's nothing wrong with Arial, Helvetica, Sans-serif CSS example: @font-face { font-family: 'Arimo'; src: url("fonts/Arimo-Regular.eot"); src: url("fonts/Arimo-Regular.svg#Arimo") format("svg"), url("fonts/Arimo-Regular.eot?#iefix") format("embedded-opentype"), url("fonts/Arimo-Regular.woff") format("woff"), url("fonts/Arimo-Regular.ttf") format("truetype"); font-weight: normal; font-style: normal; }

Hi FvG I think this is an issue with variable scope. One easy way to resolve this is to just use the wire() function, instead of the variable. In your first example, it would just change to: var_dump( wire('pages')->get('/news/') ); That should then work as expected.

Chrome web font issue on Windows: It looks like a fix for this is in the pipeline for Chrome - https://code.google.com/p/chromium/issues/detail?id=25541. KendoUI looks like a great replacement for jQuery UI, thanks for sharing interrobang.

Chrome on Windows does have a problem with rendering TrueType web fonts jaggedly, especially at small sizes. The best solution I've seen is SVG as demo'd and documented here - http://www.fontspring.com/blog/smoother-web-font-rendering-chrome. (I mainly use Chrome on Windows 7, and this Chrome issue bugs me a lot)

I really like the design of the site, good work

Thanks diogo for mentioning Cassius - giving them a whirl now Lately I've been enjoying more post-rock. On top of my usual go-to Maserati, I've now discovered some great music by Lights & Motion, Caspian and Moonlit Sailor.

I think the best way would be to do this with a bit of code. Use a selector to find all the pages with images you want to edit, iterate through them all, remove the existing image, and then just add your own. For example: $pages = wire('pages')->find("template=property"); foreach ($pages as $page) { $page->images->deleteAll(); $page->images->add("http://images.com/image1.jpg"); $page->save(); } I haven't tested that on a site, but you get the idea. You could have that code in a template file, or in a separate PHP file and include ProcessWire - as explained here.

The one I noticed previously is now gone or has been corrected, and everything else looks good! Excellent work though. The overall feel and finish of the site is of a very high standard. I like it

Great photography, and the design really compliments your work. Like it

Looking at implementing or using transactions is probably going to lead to a dead end. Transactions are not supported at the database level for tables that use the MyISAM storage engine (which all of the ProcessWire tables use) - at least, to my most recent knowledge of MySQL versions.

I think one of the responses, is that the "here today, gone tomorrow" train of thought can apply to anything. But to provide some reassurance, one of the things you can look at is the community - a good size and decent amount of recent activity are a good indicator that the project is "alive". Another is to read into the reasons why it came into existence in the first place, and how/why it still exists today - which I believe Ryan has covered both on the website, and quoted in several places on the forum (paraphrasing - "the project is funded by the paid-for modules and by people paying to have websites built using it"). The fact that it is open source is surely another winning point. The code is out there now - there is no way to retract what's already been published, it can always be forked and maintained by any interested party. And it's PHP and MySQL - there are no shortage of developers with those skills. Several of the things mentioned above are also true of WordPress (and others!). I do believe that some people and organisations hear about these "wonderful" open source CMSs (WordPress, Drupal) and use those as the baseline to judge anything else against. But as we know, those tools aren't always necessarily up to what they promise. Perhaps a collection of proper case studies of sites built with ProcessWire, involving the developers/clients, would be a great help in this area. Particularly if some were "high profile" to grab people's attention.

You're welcome. Just use everything until you find something that works for you

I'll second that - it looks amazing!