Leaderboard

Easy answer: PW uses the MyISAM storage engine, which does not support foreign key constraints. InnoDB could be considered at some point because it has some benefits and also full text search for a while now. But to my knowledge MyISAM still outperforms InnoDB in some areas and there are more things to consider.

Hey, I really love the functionality of Hanna Code. But it's 45mb (!!!) because of the ACE editor. So my idea is to change it to work like my Template-Editor module: Use ACE in case it is installed and otherwise implement only a tab functionality. That should work as well and save some space (and upload time!). Here's the part of codes that could just be copied into hanna code: https://github.com/NicoKnoll/ProcessTemplateEditor/blob/master/ProcessTemplateEditor.js#L1-L19 Thanks, Nico

I'm sure pagetable does hook into pages::delete for the exact same reason, therefore I'm quite certain the standart pagefields do so, too.

Hi Fred Just in regards to this comment above - your other thread was posted on a Friday and it's the weekend so I'm sure people will chime in during the week if they can help (the forums are almost always quieter on the weekend). Any replies in the forums are from community members giving up their time to help - there is no guaranteed support, so please be patient if you don't receive any replies for a day or two when posting.

This module was already introduced in another thread yesterday, but since each module should have a thread of its own, here we go. Login Scheduler adds a couple of new fields to user template(s) and provides support for disabling login for non-superuser accounts either instantly (with a checkbox, "Login disabled") or by specifying a time range ("Login allowed starting from", "Login allowed until"). If a user is already logged in when login access is disabled, logout should be triggered during next session validity check (usually next page load). Starting from version 1.1.0, superuser accounts are not affected by this module at all. This is a safety mechanism and prevents you from locking yourself out of the whole system. You can grab this module from GitHub: https://github.com/teppokoivula/LoginScheduler.

Hey, as I often just copy someone else's (sometimes my own) modules structure as a starting point for a new module I thought there has to be a better way to archive that. That's why I created the "ProcessWire Module Generator": modules.pw If something missing? Or some more wishes for options or best practices? Let me know Here's a screenshot:

Hello everybody, while debugging I imported the processwire database into Mysql Workbench and looked at the ERP diagram. I was wondering that no foreign keys are used anywhere. This can lead to data inconsistency due to any programming error when the PHP scripts are responsible for this. I can imagine that this might have been the reason for my other problems. Is there are good reason not to use foreign keys? Regards, Fred

@LostKobrakai: thanks! @horst: thanks. Reasoning: Q is common/basic => get quick & definite answer => save lifetime for all interested non-developers starting from myself) I also think that as there is no definite answer yet - Q even is more useful to all (& not only non-developers) than I initially thought.

ProcessWire and ProCache both run on LiteSpeed with no changes needed.

I'm also using a small module to hook the ace extended module into the "Custom PHP Code" option of page-fields and it just falls back to doing nothing if ace is not installed.

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

I'll vote for Ivan's suggestion. I do think that's the right way to go, as it keeps discussions in one place and not scattered around the web.

I think something like PW should be a page on FB rather than a group. If you have a page, you post from the page's name not from your own. So you do not annoy your family and friends)) As all meaningfull discussion is here in the forums I do not see any reason for maintaining a PW group. As a page we can have presence on FB with announcements and so bringing FB public to this forum. Private group will not serve as a kind of ad for PW.

I think officially pw is just on Twitter. Fb, google+, irc etc are all "community driven communities". FB probably works better as hidden, though I think it has big overlap with this forum anyways. I don't post to fb because my friends mught see that on their walls, but because I find bigger audience from here.