ProcessWire Dev Branch

[ryan]

I just pushed ProcessWire v2.3.1 to the dev branch. This is a fairly major change in that it switches the DB driver from mysqli to PDO. It meant changes to a large percentage of core files. ProcessWire still supports mysqli, but doesn't attempt to use it unless a module or a template asks for it via the $db API variable. The new API variable (for the PDO driver) is $database. More about PDO at php.net

If you are using the dev branch, be careful and test thoroughly with this latest commit to it. Before upgrading, you may want to double check that your PHP supports PDO by looking at your phpinfo (CMD-F or CTRL-F for "PDO"), especially if you are running PHP 5.2.x (where PDO wasn't compiled in by default). Though if you are running PHP 5.2 (vs 5.3.8+) then you may want to just stick with ProcessWire 2.3.0 and upgrade your PHP version when possible. 

If you are using any modules that use the procedural version of mysqli functions (vs. the $this->db object oriented versions), or type-hint mysqli in methods, then those modules will no longer work. If you come across any modules that don't work with 2.3.1, please let me know here so that I can assist the author in updating them.

Note that FormBuilder is one of the modules that does not work with 2.3.1, but I have posted an update in the FormBuilder board that corrects it–so be sure to download that version if you are tracking the dev branch of ProcessWire and using FormBuilder.

What this new version adds: 

1. New API variable $database that refers to the PDO database. The old $db API variable is still there and refers to mysqli for any modules that continue to use it. 

2. New API variable $log that lets you easily log messages or errors to the system logs. Usage:

$log->message("This saves this line to messages.txt"); 
$log->error("This saves this line to to errors.txt"); 
$log->save("my-log", "This saves this line to my-log.txt"); 

// Get an array of the last few entries saved to the messages log
$entries = $log->get('messages'); 

// Get an array of the last 50 entries saved to my-log
$entries = $log->get('my-log', 50); 

Note that as always, log files are located in /site/assets/logs/. 

3. Conditional autoload modules. In PHP 5.3+, modules may now specify an anonymous function OR a selector string, rather than a boolean for the 'autoload' property returned by getModuleInfo(). PW runs the anonymous function after determining the current $page, so your module can make autoload decisions based on the $page (or any other factor you'd like), if desired. Lets say that we have a module that we only want to autoload when the template is 'admin': 

public static function getModuleInfo() {
  return array(
    'title' => 'Module Title',
    'summary' => 'Summary text...',
    'version' => 1, 
    'autoload' => function() {
        if(wire('page')->template == 'admin') return true;
          else return false; 
    }); 
}

And the same example but using a selector for autoload: 

public static function getModuleInfo() {
  return array(
    'title' => 'Module Title',
    'summary' => 'Summary text...',
    'version' => 1, 
    'autoload' => 'template=admin'
    ); 
}

4. Addition of $pages->add() method. Actually $pages->add($template, $parent, [string $name], [array $values]); This function adds a new page to the database and returns it. This is for syntax convenience, but using the old method is still perfectly fine too. Here's a few examples of usage:

// add a new page using template basic-page under /about/
$newpage = $pages->add('basic-page', '/about/'); 

// same as above, but named 'contact'
$newpage = $pages->add('basic-page', '/about/', 'contact'); 

// same, but populate the title field too
$newpage = $pages->add('basic-page', '/about/', 'contact', array('title' => 'Contact Us')); 

// you can also do this, specifying the values array as 3rd argument:
$newpage = $pages->add('basic-page', '/about/', array('title' => 'Contact Us')); 

$template and $parent are required, but may be objects, IDs, or string identifiers (like name for template, or path for page). When you add a new page and don't specify a 'name', then PW will make one up, guaranteed to be unique.

5. Module files that end in '.module.php' are now supported. So rather than ClassName.module, you may use ClassName.module.php if you prefer it. The purpose here is to support text editors that determine their syntax highlighting based on the file extension. 

More updates being made almost daily. Please report any issues you experience.

Thanks,

Ryan

[Pete]

#2 & #4 - more work for Soma on the cheatsheet - that will keep him happy

Am I right in thinking number 3 is pretty huge, especially if you have a lot of autoload files that don't already check page/template/something-else in their functions? It sounds useful in terms of now having a standard place to define when the module will run

Good stuff all round!

[Soma]

But now cheatsheet is a PW site and Ryan can edit it easily himself.

[DaveP]

One of the many things I love about PW is that whenever new features are added they always make sense. Not just Ryan's excellent descriptions, but the additions themselves. In this case I especially like the $pages->add method. 

[Pete]

But now cheatsheet is a PW site and Ryan can edit it easily himself.

But what would you have left to do then? Oh yeah, more modules. Good point

[kongondo]

+1 for $pages->add();

[MatthewSchenker]

Greetings Everyone,

Excellent progress Ryan! Very exciting!!!

Quick and (perhaps obvious) question: when using the new $pages->add() feature, can the array specify more fields the template uses for that page?

For example:

$newpage = $pages->add('basic-page', '/about/', array(

'title' => 'Contact Us',

'firstname' => 'Ryan',

'lastname' => 'Cramer',

'description' => 'Master coder and genius community leader'

)

);

Where "firstname," "lastname," and "description" are fields created and added to the "basic-page" template via the admin area?

Thanks again for your amazing work and commitment!

Matthew

[slkwrm]

@Matthew Haven't tried this new feature yet, but I'm pretty sure array option is here just to make it usable the way you pointed. Gonna try it soon  Nice addition!

[pwired]

If you are using any modules that use the procedural version of

mysqli functions (vs. the $this->db object oriented versions), or

type-hint mysqli in methods, then those modules will no longer work. If

you come across any modules that don't work with 2.3.1, please let me

know here so that I can assist the author in updating them.

Note that FormBuilder is one of the modules that does not work with

2.3.1, but I have posted an update in the FormBuilder board that

corrects it–so be sure to download that version if you are tracking the

dev branch of ProcessWire and using FormBuilder.

Don't get me wrong here but If I read all that I get a bit afraid again. I came from modx evo to processwire because the modx team stopped development for modx evo and evo was no longer compatible with php 5.3.x and up. There was lot's of turmoil going on in the mod evo world. No need to repeat all that because this is all well known and heavily discussed all over the forums. {Disclaimer: Any modx user or amb reading this, yes I am aware that modx evo is kept alive by forks and usergroups especially by superuser yama} Lot's of modx evo users migrated to processwire. I am not a professional (php) template coder like most of you people here who can help themselves if some things stop to work with pw upgrades such as this one or with a php upgrade. If I see this pw 2.3.1 upgrade issue unnecessary wrong as I post here and / or there will be no future problems like happened with modx evo when php upgraded on many hosters to 5.3.x please reply and take my worries away.

[diogo]

@pwired, there isn't any software that keeps compatibility with old versions of modules forever. That's why I think it's great that you don't have to use lots of third party modules with ProcessWire, and everyone should be aware of the risk of making a website completely dependent of them. Anyway, no one is forced to upgrade immediately to a latest version (or even at all), and Ryan shows he is always very concerned about breaking things for people, so I'm pretty sure that when it comes the time when that step really has to be taken, all modules (or a good alternative to them) will be already compatible.

One thing I think it's important to keep in mind here is that software has to evolve. And this evolution will always be a balance between backwards compatibility and new and better features. You really don't want to use a software that stopped in time...

[apeisa]

I have used ProcessWire 2½ years and only real issues with upgrades where at 2.0 => 2.1, when whole user management got huge overhaul. And by "real issues" I mean that upgrading required something else than just updating the core files.

I has been smooth ride and I am super excited about the great development phase. But maybe 2.3.1 dev should be called 2.4 when released as stable, if it might not work with some modules?

[Gi∂vanni]

The switch to PDO is an important milestone! Way to go!

[ryan]

But now cheatsheet is a PW site and Ryan can edit it easily himself.

And I've started to do it (the section for WireArray is now updated). The system Soma put together here is fantastic. 

Quick and (perhaps obvious) question: when using the new $pages->add() feature, can the array specify more fields the template uses for that page?

Yes it can. Though I think $pages->add() is mainly useful without going to far on the fields there. I still find the regular syntax (populating the field values directly to the $page object) the most readable. 

Don't get me wrong here but If I read all that I get a bit afraid again. I came from modx evo to processwire because the modx team stopped development for modx evo and evo was no longer compatible with php 5.3.x and up. There was lot's of turmoil going on in the mod evo world.

I'm a little confused, as there aren't any parallels between MODX and ProcessWire in this regard. Though if ProcessWire were to stop evolving, then maybe that would be a parallel with Evo? (though glad to hear others are working on continuing Evo). No plans to stop evolving here. Switching to PDO, then namespaces and composer support is part of that evolution. This evolution is important for ProcessWire to grow and ensuring it remains the best tool for the job. 

If I see this pw 2.3.1 upgrade issue unnecessary wrong as I post here and / or there will be no future problems like happened with modx evo when php upgraded on many hosters to 5.3.x please reply and take my worries away.

All ProcessWire upgrades are optional of course. You don't have to upgrade unless you want to. I'm still running Photoshop CS3. ProcessWire is a big enough software that some changes will be more valuable to some than others, depending on what you are doing with it. 

As ProcessWire evolves, sometimes modules that want to support it will also have to evolve. As for now, FormBuilder is the only module I'm currently aware of that had to be updated in order to keep working with this version. That's not really a surprise, as FormBuilder is probably the most complex PW module out there. There may be more, but none that I've come across yet.

What I'm much more shy about is doing anything that would require changes to one's site templates. I see API syntax as locked for changes, but not additions. We would version the API if any major syntax changes were ever necessary. So upgrading from one version of PW to another should rarely if ever require changes to your own site templates, unless your site templates are doing some very low level stuff. 

As for server, PHP 5.2 was EOL'd by the PHP team more than 3 years ago. They are no longer updating it. Meaning, none of us should still be using it, at least not for current projects we are maintaining or keeping up-to-date. Trying to maintain PHP 5.2 compatibility through future versions would be a drag on the project and people's usage and perception of it. 

[vsulin]

Hi all,

as a developer I only care that there is "atleast one stable version" which supports both legacy and new api that gives developers soft transition period to update their modules.

Besides as this is already done with the "oo mysqli" that is available current and upcoming PDO Processwire. Thus we have "no real problem" because all modules can be updated now so they work in the current and upcoming PDO Processwire. And using PDO-only db api in your module as soon as it is available would only break backward compability for your module.

[ceberlin]

I tried the latest dev and had trouble (which I had not before) with certain serarches:

1. the admin search: clicking on the number-link at the headline of a template editing page (showing the pages that use that template) gave empty results;

2. Switching to Edit this page (from the silver admin bar) gave an empty search page instead of the page with the edit overlay.

[ryan]

1. the admin search: clicking on the number-link at the headline of a template editing page (showing the pages that use that template) gave empty results;

Thanks for finding it. Looks like a bug, but an easy fix that will be committed later today. I missed it because I'd changed my default search operator to %=, which doesn't exhibit the issue. 

2. Switching to Edit this page (from the silver admin bar) gave an empty search page instead of the page with the edit overlay.

What is the silver admin bar? Is this the AdminBar module or something different?

[ceberlin]

>What is the silver admin bar? Is this the AdminBar module or something different?

Yes, this is the AdminBar module, I believe. It feels so natural to use it, I thought this is part of PW

[ryan]

AdminBar is great I agree. But I'm so set in my old ways that I still always just place my own edit button in the top left corner, and nothing else. So I haven't yet had the opportunity to test AdminBar with 2.3.1. I'll install AdminBar and see if I can figure out what the issue might be. 

[ryan]

Okay just tested with AdminBar, and man it is nice to see it again. Everything works for me. I think I'm going to keep it here. You might want to check your site to see if you've got any JS errors or anything like that. If I understand how AdminBar works correctly, it could be interrupted if you had something else on your page triggering a JS error, or didn't have jQuery or something (possibly jQuery version?)

[ryan]

Some fun stuff just pushed to the dev branch: the core now includes a Modules Manager "Lite". The screenshots below best describe how it works. But it lets you install  modules from the directory just by typing (or pasting) in the module's class name. It also provides a 1-click capability to check for a given module's updates and upgrade it when necessary. 

Beyond that, the modules screen is now split into tabs: Site, Core and New. Site shows just your /site/modules/, and Core shows just your /wire/modules/. The New tab is where you can install modules. 

I really wanted a solution that kept the actual browsing for modules out of the CMS. Not because I think it's a bad idea (it's a great idea) but because I wanted the modules directory (modules.processwire.com) to serve that purpose as much as possible, at least as a default. That way I don't have to worry about scalability as the size of the modules directory increases. Plus less automation might make the newbies be a little more careful about what they are installing and where it's coming from. The power of the automation in ModulesManager here is so powerful it scares me, so think it's better for the users that know what they are doing. Lastly, ModulesManager is one of the best modules out there and Soma does an amazing job with it. Bringing a little taste of ModulesManager into the core I thought would help both projects. 

Most credit for the new core "Modules Manager Lite" goes to Soma (though he doesn't yet know that). It's all built around his code lifted directly from Modules Manager. Hope that's okay Soma? Your code now powers not just the new stuff in ProcessModule, but also the new WireHttp::download function, and the new wireUnzipFile() function, all added this week. 

People who want the most power will still want to use Soma's Modules Manager. That does a whole lot more than the built-in one does, including installation of themes, checking for updates en-masse, and browsing and filtering through the modules directory. But now you can install ModulesManager or other modules without having to manually FTP things to your server (so long as your /site/modules/ is writable). Please let me know if you guys run into any issues with it. 

[Soma]

Take all my code and money too. Well the latter comes in form of code.    

Serious, I'm very proud to have played a role. I agree with what you said and will first go check it out and come back later...

[kongondo]

Nice! 

+1 one for separation of core and site...

[Soma]

There's a bug in Functions.php I just filed a issue on github.

I just tried to enter a module name that already is installed, and it checks beautifully for that and says it's installed but older version. This is meant to be a way to update the module too? I then hit download, but it felt wierd. It may would be cool then to have the title or message then say an update is available more clear? And the button called "Download v0.1.3 update" or something.

[ryan]

This is meant to be a way to update the module too?

It is, though I figured most would use the "check for updates" link in the module settings. But it uses the same function as the install, just for DRY reasons.

I then hit download, but it felt wierd.

Felt weird? Maybe be a little more gentle... lightly tap, don't hit. 

It may would be cool then to have the title or message then say an update is available more clear?

Good idea, I'll add a $this->message("update is available"); or something along those lines. 

And the button called "Download v0.1.3 update" or something.

Also a good idea, I'll add it this morning if possible. 

[Soma]

I'm maybe going crazy, but on a install I'm working on since long time I have updated to latest dev.

Now I have an empty "Session" on the setup menu. Missing process... 

Wasn't there a core module once for sessions? I can't find any Session modules.

Also I'm looking for the Login Throttle module and can't find it anymore. What happened?