Leaderboard

Around PW 3.0, I'm looking to make PW multi-instance compatible so that you could have multiple ProcessWire instances (each connected to separate databases) running from the same PHP code. This opens a huge amount of flexibility. But it also means that any kind of static references will have to disappear because function calls like Wire::getFuel('var') and wire('var') make the assumption that there is only one instance of ProcessWire running. This is one of the bad things about static calls in general. When that time comes, we will be able to apply contexts to our template files so that calls like wire('var') still work. But the reality is that non-static calls like $this->wire('var'), $this->var, and $var are technically superior when it comes to a multi-instance environment. So my opinion would be that it's not good to introduce new static calling methods when they may soon be obsolete.

Just pushed up some improvements to the DiagnoseDatabase module. It now takes more time poking around with character sets, collations and table information. Here's a couple of screenshots... Hope these might eventually help someone out.

OMG, Ryan! Then I need for sure a seat belt at the office chair, avoiding liftoff.

Note to self: Never, I said never, accidentily delete the first line ("<?php") of PW's index.php file and save it! Punishment: On next trip to post office collect, fill out and submit form id10t. In triplicate.

This is one of those things that gets everyone every now and then. One way to to avoid it is to define them in opposite order, so if you accidentally forget the second = you will get an error, instead of setting the variable to the value Like this: if ("typical-day" = $page->template) will throw a parse error, but with "==" it will work as expected. As for whether you should change templates at run-time - there should be no problems doing this and it can be quite powerful.

Hey Pete, could may add a map with all of the users based on their given location on it? (I think we had this topic already once but I'm not sure ) http://community.invisionpower.com/files/file/3070-member-map/ -- Nico

What you want is: if($page->template == 'album'){ The $page variable is the current page in PW, so this returns the template for this page.

oUCH >_< sorry to hear that bwakad. But love the idea of PWers being pins on a Google Map; would be like getting to know a good neighbourhood

The Module Blog for ProcessWire replicates and extends the popular Blog Profile. Blog is now in version 2. Please read the README in the Github link below in its entirety before using this module As of 20 December 2017 ProcessWire versions earlier than 3.x are not supported Blog Documentation is here (Work in Progress!) See this post for new features in version 2 or the readme in GitHub. To upgrade from version 1, see these instructions. ################################################## Most of the text below refers to Blog version 1 (left here for posterity). Blog version 1 consists of two modules: ProcessBlog: Manage Blog in the backend/Admin. MarkupBlog: Display Blog in the frontend. Being a module, Blog can be installed in both fresh and existing sites. Note, however, that presently, ProcessBlog is not compatible with existing installs of the Blog Profile. This is because of various structural and naming differences in respect of Fields, Templates, Template Files and Pages. If there is demand for such compatibility, I will code a separate version for managing Blog Profile installs. In order to use the 'Recent Tweets Widget', you will need to separately install and setup the module 'MarkupTwitterFeed'. Please read the README in the Github link below in its entirety before using this module (especially the bit about the Pages, etc. created by the module). I'll appreciate Beta testers, thanks! Stable release works fine. Download Modules Directory: http://modules.processwire.com/modules/process-blog/ Github: https://github.com/kongondo/Blog You can also install from right within your ProcessWire install. Screenshots (Blog version 1) Video Demos ProcessBlog MarkupBlog Credits Ryan Cramer The Alpha Testers and 'Critics' License GPL2

This is pretty neat: https://pushover.net/ I had been thinking it would be great to have a notification app that you could somehow use with ProcessWire and this - with a little programming - would do nicely! Notifications of new comments on your site? No problem. Built your own client support system in PW? Get push notifications of new tickets. The possibilities are endless and the price tag isn't bad - free for up to 7,500 notifications per month and only $4.99 per user for the app In fact, I already know a few clients who would love notifications of certain things to arrive this way!

DiagnoseAndRepairDatabase.module

@horst You read my mind. I'm out until tomorrow evening but that happens to be next on my to-do-list for DiagnoseDatabase. @Martijn Thank you! It's really nice to have input from Nico, horst and Manfred62. Hope it is useful to folks!

No, I'm from Portugal but am frequently in Frankfurt. Sorry for hijacking the Berlin thread

Just read again, and what you say is already like this. ProcessPageList is a module used by other like InputfieldPageListSelect. You could also used it in your module. But as you see even in other places it just works even if never was intentional to be used on front-end. Parent can be set also using $config->js Edit: Corrected my example above, as the $config->js(...) part isn't needed to configure. That's what the module does, I just had some order wrong. First call execute, then output the $config->js. Or like kongondo demonstrated for in modules.

ups, I missed that tiny button, thanks adrian. the editor is me

I added caching to DiagnoseModules. (see Pull-Request)

@adrian @Nico Knoll @horst. Thanks alot for your response, ok let me try these basic steps you just gave to me now let me see how it goes. Thanks

@videokid: ok that with readability is personal. agread but what trick does it? if($upload_path.$filename !== $upload_path . $filename) echo 'Horst is wrong!'; else echo 'This is nonsense!';

OMG. Found the error! This needs to be a cautionary tale to others. I had this code in the head section: <?php if ($page->template = "typical-day"): ?> <!-- some files get added here--> <?php endif ?> As you can see there is a "=" sorely missing there (i miss-typed or was just tired, have no clue how it happened). So it ended up changing the template of the page instead of just checking if it was set to "typical day". The "typical-day" template obviously did not even have the "homepage_slideshow" field assigned to it. On the bright side That is something very cool to be able to do (changing the template on run-time), which might have some interesting applications. Is that something one should do or should we stay away from it?

if you say need to show a script on multiple templates , then you can use $page->is, like this; <?php if ($page->is('template=work-index|gallery|videos')) { ?> scripts here <?php } ?> and when you start setting up to use AIOM+, you can then us selectors to load particular scripts with a processwire selector: <?php $jsfiles = array('assets/js/plugins.js', array('loadOn' => 'template=work-index', 'files' => array( 'assets/3rd/dataTables/jquery.dataTables.min.js', 'assets/3rd/magnific/jquery.magnific-popup.min.js' ) ), 'assets/js/main.js', 'assets/js/vendor/retina.js', ); ?> <script type="text/javascript" src="<?php echo AIOM::JS($jsfiles); ?>"></script>

This module is improved and extended successor to Version Control For Text Fields. It handles everything it's predecessor did -- providing basic version control features for page content -- and quite a bit more. Download or clone from GitHub: https://github.com/teppokoivula/VersionControl. This module requires ProcessWire 2.4.1 or later, mostly because of the file features, which require certain Pagefile and Pageimage methods to be hookable. There's no sensible way around this limitation; for those stuck with < 2.4.1, Version Control For Text Fields will remain a viable option. What does it do? While editing pages, fields with old revisions available show up with a new icon in their header bars. By hovering that icon you get a list of available revisions and by clicking any one of those the value of that particular field is reverted to that revision. No changes are made to page until you choose a revision and save the page, which means that you can keep switching between revisions to get an idea what's really changed without inadvertently causing any content to change. The module also adds a History tab to page edit. This tab opens a view to the history of current page in the form of "revisions" -- each of which is a group of changes to page fields processed during one page save (similar to revisions in various source control applications). There are three actions you can perform on these revisions: adding comments, live previewing what the page might've looked in that revision and restoring the page to specific revision. One specific feature that has been a big thing for me personally is support for file (and image) fields, as the original version control module felt rather incomplete without it. I'm hoping to take this a lot further performance, stability and feature wise, but as it stands right now, it's already included here and should be fully functional. Watch the video preview here I prepared a little screencast outlining most of this: http://youtu.be/AkEt3W7meic. Considering that it was my first screencast ever, I'd like to think that it wasn't that bad.. but I might give it another shot at some point, this time planning a bit before hitting "record" Upgrading from Version Control For Text Fields For those already using Version Control For Text Fields, I've added something extra. If you upgrade that module to it's latest version, you should see a new checkbox in it's settings screen saying "Don't drop tables during uninstall". If you check this, uninstall the module and then remove it's files (this is required in order to install Version Control), your old data should be automagically imported to Version Control. Import has only been tested with limited amounts of demo data. Proper tests are yet to come, so please be careful with this feature! Update, 21.6.2015: as of today, this module is no longer in beta. While all the regular warnings still apply (making changes, including installing any new modules, on a production site should always be considered risky) Version Control has gone through pretty extensive testing, and should be as stable as any other module out there.

Please use Matrix Fieldtype & Inputfield Or the ProFields. FieldtypeJson (module) Álpha I've been busy last 2 weeks with a new fieldtype. I needed a fieldtype that generates JSON strings from CSV (excel data). I needed a way to handle a variable amount of columns & needed a way to manage that data. Wanze & Kongondo already worked on a excel crud module with the excellent Excel-like data grid editor Handsontable and I loved that piece of software. Thank you guys. Handsontable is used in the Inputfield part. What the Inputfield does does: If there's no data in the field, the Inputfield shows you a textarea. You could copy 'n past in CSV text in that field. When you save the field, all data is processed. Processing means: Slice till an x amount of data rows. If minimum amount of columns is not reached, pad the columns till the amount you've specified in the settings If the data contains to much columns, slice the redundant amount of columns. Every data left, is trimmed and sanitized Every numbered string will be converted to integers Saved in 2 formats: 1) json and 2) cvs Server side there's a lot of processing needed to perform all this, that is the reason to set a low amount of data rows. On The Inputfield side, the JSON is generated by Handsontable. So this feels a bit dirty. (Server side it does do all the steps in the above list.) For now it's called FieldtypeJson, but i'm not to keen on this name. Output How to output in your template: $page->fieldname // (string) the table markup $page->fieldname->json // (string) JSON string $page->fieldname->csv // (string) CSV string $page->fieldname->rows // (int) number of rows, not really usefull, but needed internally $page->fieldname->columns // (int) number of columns, not really usefull, but needed internally When to use: If you need a small set tabular json data, and you don't know how many columns it has. If you want to have render tables quicky in your site. When not to use: Store very large sets of query -able data. If you have to rely rely on the data. ( all json is stored in a subfield, and the same for csv ) API Side (JSON): // Json string $json = '[["First Name","Last Name","Company Name","Address","City","State","Post","Phone","Email"],["Rebbecca","Didio","Brandt, Jonathan F Esq","171 E 24th St","Leith","TA","7315","03-8174-9123","rebbecca.didio@didio.com.au"],["Stevie","Hallo","Landrum Temporary Services","22222 Acoma St","Proston","QL","4613","07-9997-3366","stevie.hallo@hotmail.com"],["Mariko","Stayer","Inabinet, Macre Esq","534 Schoenborn St #51","Hamel","WA","6215","08-5558-9019","mariko_stayer@hotmail.com"]]'; $page->of(false); // Turn OutputFormatting of $page->fieldname->json = $json; $page->save(); $page->of(true); API Side (CSV): // CSV string $csv = '"First Name","Last Name","Company Name",Address,City,State,Post,Phone,Email Rebbecca,Didio,"Brandt, Jonathan F Esq","171 E 24th St",Leith,TA,7315,03-8174-9123,rebbecca.didio@didio.com.au Stevie,Hallo,"Landrum Temporary Services","22222 Acoma St",Proston,QL,4613,07-9997-3366,stevie.hallo@hotmail.com Mariko,Stayer,"Inabinet, Macre Esq","534 Schoenborn St #51",Hamel,WA,6215,08-5558-9019,mariko_stayer@hotmail.com'; $page->of(false); // Turn OutputFormatting of $page->fieldname->csv = $csv; $page->save(); $page->of(true); After save, all other subfield are updated. So saving JSON will update CSV and the rows and the columns. And saving CSV will update JSON and the rows and the columns. Saving direct to the fieldname, or saving to both json and csv or saving to the rows & columns wil thow a wireException(). Download: source on github Warning: This Fieldtype is Álpha, don't use it in live projects empty field: paste data: imported data: manage data: settings:

AFAIK it's not a standalone right now, is it? Would be cool to have it as a markup module so that other modules could use it as well, the core would use it this way then too. It should be definable what the root page of the tree is, so that it can be used very flexibly. whaddayathink?

PageTable is new kind of fieldtype, coming in 2.5, but already available at dev branch. I think it has best parts of page and repeater fields combined. It allows creating and editing linked pages in modal, without leaving the page you are actually editing.

Oh, also something to think about – I don't know how you guys handle this, and it obviously depends very much on the project and the modules used. I think translations are (mostly) for users, e.g. editors. Admins should be able to handle a PW backend in English, although I wouldn't call it a requirement. However, I wouldn't know how someone who doesn't read English would even be able to understand PW enough to administrate a PW installation. Most of the documentation is in English only. So in most of my projects, clients have a “backup” admin account, but use PW as editors, which means they don't get to see much more than the page tree, which is a core feature. What I'm trying to say is maybe we're overthinking modules translations quite a bit here. Yes, they would be nice to have, yes, it would be nice to have a way to easily install them. But if someone definitely wants a module's backend section translated, a bit of work to install the translation should be fine.

Personally, I would not even consider translating that because ModulesManager is more like a proper name. You usually don't translates proper names. (By the way, Soma is very right considering fragmenting discussion by translations. I have experienced that in a forum for another system. It's very hard to switch. However, it's something you can't really avoid – once a system is translated, people will discuss it in various languages.) The issue at hand with this is still if we should put module translations in the “core” language files or not. Personally, I don't think it's a good idea. It would blow up the language packs significantly, which is not ideal for people who don't use many modules. (I, for instance, tend to not use many modules in most of my PW projects.) As for keeping all translations for modules in a seperate repository, I don't think that's much better. The repository will grow rather quickly, making it hard to install only the few translations people actually need, especially given the fact that the file names for translation files are kind of clumsy. I think the only option there would be to keep the modules in seperate directories of that repository. I don't know if that's feasible, but maybe module translations could get some kind of a “dependency management”? Currently, if you install a translation, you just upload a zip file including all core translations. (At least that's what I do.) It would be very awesome if there was a way to (for each language installed) easily “get all available translations for modules currently installed”. (Might be kind of an overhead, though. Not sure. I'm not a coder.)

Every module is sort of standalone more or less. But I don't see the PageTree being very useful for front-end as it's built for the backend usage. It's geared a lot towards PW admin usage and not meant as a tree like other plugins out there jQueryJSTree. Though as with most in PW it's fairly easy get a admin page tree working in your templates. After all the backend also is just a website. PageTree need the css, js and a js config to work. So it would work like this but on only show pages when logged in of course. Admin processes aren't accessible for not logged in users and PageTree uses ajax. <?php /** * Page template * */ // load page list module $tree = $modules->ProcessPageList; $tree->id = 1001; $output = $tree->execute(); include("./head.inc"); // output the container markup, the rest does the js echo $ouput; And head.inc would need this to autoload assets and write the config js. <script type="text/javascript"> <?php $jsConfig = $config->js(); $jsConfig['debug'] = $config->debug; $jsConfig['urls'] = array( 'root' => $config->urls->root ); ?> var config = <?php echo json_encode($jsConfig); ?>; </script> <?php foreach($config->styles->unique() as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; ?> <?php foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> Edited for simpler version.

$p = $this->modules->get('ProcessPageList'); $p->set('id',1234); // the parent page return $p->execute(); Is that what you meant? I have a feeling I am wrong!

Diogo and I met once in Berlin

Yeah I was speaking about things only visible to devs, but it would feel odd and there's no clear line or hard to see/know, so as said the modules title makes sense to me not to translate. This wouldn't be too bad as everyone would be speaking of "ModulesManager" and not "ErweiterungsVerwalter".

Great news Ryan. Would it then not be possible to make even the static calls like wire('var') aware of their contexts? I mean at the moment a wire('page') call is ware of it's page context, it knows on which pare we are currently on. In classes, couldn't we apply that also to some kind of DB context awareness then? How would a module know on which PW instance it's currently working on? I assume that the instance properties, like $this->input or $this->page are somehow set in the background and the access of them code wise would not change for a module dev, right? So why wouldn't it be possible to have a static call also have a context (PW instance)?

Has your apache version changed recently? I just got a 500 Internal Server error on my Godaddy vps and this is why, not sure if this will help you or not. (My other vps worked fine.) I was doing a new processwire install, and Godaddy was missing pdo, and gd so I did an easy apache rebuild in WHM. Then the install.php file stopped loading and started throwing a 500 error. I opened up cpanel and looked in my error log and it said: .htaccess: Invalid command 'SetEnv', perhaps misspelled or defined by a module not included in the server configuration I am planning on redoing easy apache and making sure the Env module is selected! I will let you know if that fixes mine! What is bad, is it is suppose to start with your previous config, so I am not sure how this box gets unchecked! Could be a bug! **** Edit: Yes, checking the ENV checkbox did fix my 500 issue!

A new Chrome + CKEditor bug (new to me) it seems. I certainly am seeing random SPANs with inline styles added to copy under some circumstances That previous link plus this link to Drupal seem like they may fix it, off to go and see if they do... Edit: OK, probably not going to follow the Drupal instructions since they probably refer to a Drupal system off to check here for how to add a CKEditor plugin... Not found how to enable/use this plugin so I have just installed it and am assuming it will be auto-detected and used. We'll see...

In mailChimp you can use a debug service. ( I Forget the name of this service ) You can [x] check email clients. From those results a screendump is created and the result is send back to MailChimp. This process takes from 20 minutes till 7 hours and everything in between. Some screenshots only contain the viewport, others the whole newsletter. And there's no way to see the rendered source. Responsive email can it be done? Yes it can. ( for some clients ) But you need time, lot's of time and more time. Debugging newsletters is a big big hell if you asked me.

Awesome work! Now, what if i needed to have 10 separate blogs like this on the same site?

@horst Sorry about that. Just added it to ProcessDiagnostics. Can you let me know if this version fixes it for you? Hmm, well, I messed up something on my server - looks like Apache2 is serving php files as plain text now

When you're building your array, make it multidimensional. Something like this should do the trick: $lyricsArray[$track->id]['title'] = $track->title; $lyricsArray[$track->id]['lyrics'] = $track->lyrics; Then when you a are foreach'ing it, you can: foreach ($lyricsArray as $track) { $lyricModal .= $track['title']; $lyricModal .= $track['lyrics']; } But then I am also wondering why you are converting the $track object, which already has title and lyrics, into an associative array. Is it just for the lyrics empty check? If so, then you can do that by foreaching the albumTracks object again: foreach ($albumTracks as $track) { if ($track->lyrics != null) { $lyricModal = '<div id="songID_' . $track->id .'" class="reveal-modal small" data-reveal>'; $lyricModal = '<h2>' . $track->title . '</h2>'; $lyricModal .= $track->lyrics; $lyricModal .= '<a class="close-reveal-modal">×</a>'; $lyricModal .= '</div>'; echo $lyricModal; } } Does that do what you want, or am I missing something

@steve: with the new version 0.2.0 I get an fatal error becuase of a missing method in ProcessDiagnostic. The missing function is this (from @adrian): /** * returns if function is disabled in php * * @return boolean: true, false */ static protected function isDisabled($function) { $disabled_functions = explode(',' , str_replace(' ', '', strtolower(ini_get('disable_functions')))); return in_array(strtolower($function), $disabled_functions); } @steve & @Nico: I have a question with the modules module: I don't want it to query all versions every time I call the diagnostics page. So, yes, I can uninstall it and only install it on demand. But would it not be better if this module has a button that I can press to execute the query and an option that lets select a time period (e.g. 1 week) that let run it via lazy cron at least once in the given time period?

Great, if you have this, you only need to check your actual url for the string /page and if it matches, append a / and a ?sort= to it, and if not, only append ?sort= to it. Ready. Done! Happy coding!

Maybe next time. Unfortunately yesterday I cut a muscle on top of my knee. Walking is not good now. But if you go, I mentioned an idea I had for PW: to make a location map displaying members on this forum. Should be convenient to plan these meetings in future. Just look on the map and see where more people are located. Or take some place in the middle.

Your answer is much better. I don't think those threads mention the changes on the dev version

Until recently, there has been a limit to the number of pages with images that PW can handle due to the OS per-directory file limit. However, the current development branch has changes in it that removes this previous limitation and effectively allows you to work to the full capacity of the file system. Previous limit was around 32,000 images on ext3 filesystems (if memory serves) but the dev changes blow that out of the water. Hundreds of thousands of images should now be possible but I have not verified this yet. With regard to pages, MySQL is able to handle millions of rows in tables, so I think you should be fine as long as the queries don't try to pull a lot of rows (pagination is your friend) with a lot of fields in each row. Edited to add: Beaten by diogo - again.

Hi joer80 and welcome to PW! You can get a count and list of all queries on a page like this: $queries = $database->getQueryLog(); echo '<p>Number queries: ' . count($queries) . '</p>'; foreach($queries as $query){ echo '<p>'.$query.'</p>'; } Just put that somewhere in your home template. I have to run out the door, but someone should chime in with how to use your own SQL easily. There are posts about it here. Google search is much more effective than the forum's built in one. Good luck!

Wow guys, what a warm welcome! Thanks for that. I have been toying some more with PW in the mean time, getting to know it better. Still like it a lot! It's a new way of working and thinking, but I see the big potential this system has. What I like about it very much is that you can start real simple as soon as you grasp the fundamentals, and adding more and more skills along the way. And I'm also enjoying the slickness of the interface. Very cool! I heard from another old-timer WebsiteBaker user he also has his eyes on PW. Maybe more will follow Thanks again, I'm sure I will come up with some questions in the future, but first I want to try and see how far I can come myself. Effort goes before asking, is my opinion.

Email is responsive by default.

I really liked this idea & added this setting, tnx for mentioning it @wanze It's splitted in 2 settings actually. 1. Specify the headers. 2. Start with table. This way it is possible to start with a table with or without the headers. If start with table is set, it prevents editors to see th CSV import. As in Europe (most countries) floats are divided with a comma and not divided with a point. As a result CSV data mostly use the semicolon as a delimiter. There's a setting to set the delimiter to comma semicolon or tab. In the Inputfield, the editor can upon CSV import choose which delimiter to use (by default inheriting the default setting). The force to integer setting, will recognise if the European float, and will convert this to normal float. ( heavy on CPU, so only check if needed ) @adrian, also added the ability to delete all data returning to the CSV import.

Quick 'n' dirty guide if you want a single page tree with the same content in different languages. The URLs will then look like example.com/en/my-article or example.com/de/mein-artikel 1:) Download and install ProcessWire 2:) Install the modules you find under the "Language" Tab. 3:) Go To Setup->Languages and add new languages. Please note, that the default one is also the default language of your site* 4:) For every field type text or textArea change the Type to TextAreaLanguage or TextLanguage. (e.G. body with TextArea becomes body with textAreaLanguage). You fields should now have multiple tabs for each language, if you edit a page. 5:) Go to the root page (/) and look under "Settings" Setup an URL for every language, e.g. en,de,ru,... . Looks like this: http://take.ms/34Tq5 6:) Create pages and fill in the content. You can build a front end language switch as described in Ryans API Language page. ProcessWire will take care of changing URLS (e.g. /en/example to /de/beispiel) and you can access the current language via $user->language; *It's possible later to define another language as the default language.

trackChange() is a method on every Wire derived object, which includes most of ProcessWire's objects. The question would be what you are calling trackChange() on and whether the change tracking state is on or off? Also, there are related methods, also accessible everywhere that trackChange() is: // turns change tracking ON or OFF $obj->setTrackChanges(true|false); // returns TRUE if change tracking is ON or FALSE if off $bool = $obj->trackChanges(); // returns an array of changes that have occurred $array = $obj->getChanges(); // tracks the change, only if change tracking in ON $obj->trackChange('field_name'); // clears the list of tracked changes $obj->resetTrackChanges(); // hook that is called anytime a change occurs: only useful if you want something to be notified of a change $obj->changed(); My best guess is that you may need to call $page->trackChange('field_name'); rather than the form itself. That's because the form is managing most of that on it's own, and may be clearing/resetting the trackChange call you did. Also, a page's changes are cleared after a successful save(), if that matters.

I'm very picky here. When I can I compaire with === I prefer that. This will tell me that the types are the same to.

You need to shave reno, your beard tickles in irc...