Leaderboard

Ok, the Mail Panel is now available! I have also added a new related panel called "Event Interceptor" that let's you define any Hook that you want to intercept. Much like the Mail panel, this new panel prevents the chosen hook from being executed, but instead, returns that contents of $event->object and $event->arguments in the panel instead. This may be useful for debugging all sorts of things, but my primary motivation for adding this is to prevent pages from being created when testing form submissions, by using Pages::save. Both of these panels (unlike most of the other custom ones - because there is no point, not because it's not possible) also work via AJAX calls - note that both their icons appear in the AJAX bar in the screenshot below. Note that the Mail panel will be active and intercept emails sent while it is enabled. The Event Interceptor will only work if there is a hook entered and "Set Hook" is clicked. To clear it, click "Remove Hook". Hooks need to be entered like so: Pages::save Both of these panels should be considered alpha at this stage, so please don't use on a live site just yet. Mail Panel icon colors: Green - no emails intercepted Red - at least one email intercepted Event Interceptor icon colors: Green - no hook set Orange - hook set, but nothing intercepted Red - hook set and event intercepted As I mentioned above, please consider these two panel alpha at this point, so please test carefully and give me your feedback - I expect the functionality of these to possibly change significantly based on everyone's ideas.

Hello, in one of my current projects, we have a test and production stage with their own ProcessWire installations, and we regularly want to migrate template/field configuration to the next stage without migrating content as well. ProcessWire supports this via the import/export functionality in the admin GUI. However we (and some others) would like to do this as part of an automated process. There seem to have been some discussion on this topic and two existing modules that get pretty near our requirements: https://github.com/mindplay-dk/SystemMigrations/blob/master/SystemMigrations.module https://github.com/LostKobrakai/Migrations However, they try to solve more then we need and for mindplay-dk's module, development seems to have discontinued. At that point I decided to build a more simple module with reduced scope that basically just makes ProcessWire's import/export automation-ready. Thanks in advance for trying this out and any feedback! About this Module CAUTION: This module is incompatible with repeater fields and ProFields. The module enables you to transfer template and field configuration from one processwire installation to another in an automated way. Changes to templates or fields are exported to the file system immediately (so they can be added to source control together with changes in the template files) The import script is designed to run from the command line (so it can be invoked from your build/deployment tool). On invocation in import mode, a DB backup is created template/field changes from the persist directory are imported into the DB In restore mode, the import script can restore any of the DB backups previously saved How to Use Make sure the module is installed in the source and destination ProcessWire environments. After installation of the module, you should check if the module's default persistDirectory configuration setting fits your requirements. The module will automatically export all fields, fieldgroups, and templates to JSON files in the directory specified by that setting. Note that the same setting is used by the import script as well, so if you change it, make sure you change it in all affected ProcessWire environments. The JSON files can be transferred to the destination ProcessWire environment. Running the import script from the command line will import template and field data in the destination ProcessWire environment. Manual Installation Caution: Beta software - do not use in a production environment without prior testing and regular back-ups. Caution: This module is incompatible with repeater fields and ProFields. In case automatic installation does not work, get the code at https://github.com/jaromic/pw-autoexport-tf/ and follow the instructions in README.md for manual installation. Manual Uninstall Delete the following files and directories from your module directory: AutoExportTemplatesAndFields/ AutoExportTemplatesAndFields.module Download Install from the module directory, clone the repository via GitHub, or download ZIP.

Added pull request for this issue : #14 If you want, you can apply my changes to your files or you can directly download applied version. I added 2 option for FieldtypeMapMarker module settings, api key and url parameters.

This might be a nice quick to grasp intro to using composer dependencies for a fieldtype (and creating a fieldtype): https://github.com/LostKobrakai/FieldtypeCountrySelect

Hi Ryan and crew - thanks alot for this update - awsome as usual and making me looking forward to new goodies awaiting us every next friday evening. I'm relatively new here and have become a great fan of processwire within very little time. But in 3.0.25 there seems to be a bug (or some incompatibility?): Since I updated from 3.0.24 to 3.0.25 all the "create new" links under my input-pagefields (from "allow new pages to be created from field") are gone. When replacing back the wire folder to version 3.0.22 (which I had kept) they appear again! This works back and forth. So I have a solution to work with but of course it would be nice to be able to update to higher versions. Has anybody else observed this issue? Thanks in advance for any fixing or explanation. Markus from rainy switzerland

Lots of people have been asking for a way for ProcessWire to support sending of email, outside of just using PHP's mail() function. I haven't really wanted to expand the scope of ProcessWire that deep into email sending, but I have been wanting to setup a way so that people could override how emails are sent, with modules. For people that are interested in making other ways of sending email in ProcessWire, I've setup a new module base class called WireMail, and a new function called wireMail(). The wireMail() function will use whatever WireMail module is installed. If none is installed, then it will use PW's default WireMail implementation (based on PHP's default mail function). The wireMail() function replaces all instances of PHP's mail() function in ProcessWire's source. It works in a similar way as PHP's mail() except that supports a few different usages. Standard usage would be this: // to, from, subject, body wireMail('user@domain.com', 'ryan@runs.pw', 'Mail Subject', 'Mail Body'); Another usage would be to give it no arguments, and it'll return whatever WireMail module is installed for you to use yourself. If no WireMail module is installed, then it returns ProcessWire's WireMail. $mail = wireMail(); $mail->to('user@hi.com')->from('ryan@runs.pw'); // all calls can be chained $mail->subject('Mail Subject'); $mail->body('Mail Body'); $mail->bodyHTML('<html><body><h1>Mail Body</h1></body></html>'); $mail->send(); Since all of this stuff is only on the PW 2.4 dev branch at present, I'm posting this primarily for people that are interested in creating WireMail modules. For instance, I know that both Teppo and Horst (and perhaps others?) have put together such modules and ideas, so this is all aimed at coming up with a way for those ideas to be easily integrated into PW by way of modules. To make your own WireMail module, you simply create a module that extends WireMail and provide your own implementation for the send() method. Of course, you can go further than that, but that's all that is technically necessary. I've attached an example module called WireMailTest that demonstrates a WireMail module. When installed, it is used rather than PW's WireMail. This WireMailTest module includes lots of comments for you in the code of it, and you may find it helpful to use it as your starting point. WireMailTest.module For you guys developing modules, please throw any questions my way and I'm happy to help. Likewise, let me know if you think I'm missing anything important in the base interface that the modules are based upon and we can update it.

I do not see a need for function here at all <?php // LIST PARTICIPANTS CHILDREN OF THIS PAGE $overviewchildren = ''; foreach($page->children as $participant){ $partnerID = $participant->partnerID; $overviewchildren .= '<div class="row">' . '<div class="col-sm-2">' . '</div>' . '<div class="col-sm-10">' . '<strong><a href="' . $participant->url . '">' . $participant->p_first_name . ' '; if($participant->p_middle_name) { $overviewchildren .= $participant->p_middle_name . ' '; } $overviewchildren .= $participant->p_last_name . '</a></strong><br />' . $participant->p_job_title . '<br />' . $participant->p_department . '<br />' . $pages->get("parent=1004, partnerID=$partnerID")->title . '<br />' '</div>' . '</div>'; } ?> But actually $participant->partnerID should be a Page Field so you can just write $participant->partnerID->title P.S. Note the use of get instead of find.

Many thanks to you and @adrian for answering this question and so quickly! This did indeed eliminate the error. If I may trouble the community once more for hint, I've still got the problem of trying to get the title of a page; I have found it's id but I lack the knowledge on how to grab the title. This function does not return the title of the page as I think it should (it returns nothing that I can see on the page): <?php function findPartnerTitle($partnerID){ $pageID = wire('pages')->find("template=partner-add-edit,partnerID=$partnerID"); return wire('pages')->find("id=$pageID")->title; } ?>

Like this? http://modules.processwire.com/modules/inputfield-ace-extended/

There does seem to be an issue. see i am going to be testing more later and try and submit a github issue

Pursuant to the post above by @MarcU, i am seeing the same behavior, that is the "Add New" functionality for page selects appears to be broken (ProcessWire 3.0.25 devns)

It's likely your problem is due to a XAMPP/sendmail configuration issue rather than the module. You can rule out the module by attempting to send a test email using PHP's mail() function. <?php $subject="Test mail"; $to="myaddress@somedomain.com"; $body="This is a test mail"; if (mail($to,$subject,$body)) { echo "Mail sent successfully."; } else { echo "Mail not sent."; } I found I had to jump through some hoops to get mail working in XAMPP. Here are some notes I made for getting mail to send via Gmail's SMTP server.

great! no need (and time) for testing, but i will definitifely do that asap

Just what the doctor ordered! I'm sure I'll have some cosmetic requests but at first seems very nice.

Hey @tpr and anyone else interested in the Mail panel. I have the first version up and running locally, but thought I would post a screenshot first to get some initial feedback before committing the code. Features: If the Mail Panel is enabled, it will intercept any outgoing emails - they won't be sent out, but instead, displayed in the panel. Each email sent gets its own entry which is great if you have one sent to the user and one back to the admin (or similar). You can toggle the body in text, html, and html source versions. Any initial thoughts on the layout or functionality?

Regarding 404, there has been some earlier discussion in this issue: https://github.com/ryancramerdesign/ProcessWire/issues/809. In my opinion this is not a very good design decision, but currently this is not easy to circumvent. Trash is another issue, and for that you should check out Trashman. Allowing access to trash is another design decision I find less than optimal, but luckily Trashman provides a viable alternative for that.

The 404 page is a system page like the trash and therefore only visible to superusers.

I haven't had the chance to know PW 2.1 so bear with me Well I don't care if something should belong to the core or not. If I need a feature that I can solve relatively easily with CSS/JS to simplify my admin life, I'll do it. If it makes itself into the core I'll happily remove from the module. But it's unlikely that these feature will be part of PW within months or even years, and I need them now. Even the admin themes don't change too rapidly so I have time to fix the errors. Apart from these it's fun to play with this @grimezy download the latest from GitHub, the button and matrix repeater issues should be fixed. The latter was present in simple repeaters too and that was already covered.

How do you have done the move? What local system are you using (win / mac / linux)? Have you emptied all caches, especially filecompiler? (You can use @Somas ClearCacheAdmin for this, fe.)

Just added a few CSS tweaks to the compact module list feature and it got really compact Since clicking on the module names loads the module settings page I added a small icon next to them, and hided the Settings button. It may take some time get familiar with this but I think it makes sense. Install and delete buttons are placed to the far right, so rows usually fit in one row now (depending on screen resolution and module descriptions). The delete button also got a reddish background color. Edit: module main icons are moved to the right within their cells, so module names align nicely to the left, making them more readable (otherwise modules with no icons caused "ragged" column)

Yes, you could do all the above. I don't know what you're after with those external databases, but in most cases I think it's not convenient to have separate models to work with. Keep in mind that working with hundreds of thousands of pages (data containers) in ProcessWire is no problem. I haven't seen real performance issues for sites with more than a million pages. On the other hand, ProcessWire is just executing PHP so if you wish to use external databases you go can go for it.

Hello Francesco, it depends on how you structure your files and directories. There is no general rule for it. Thats the best on PW because you can do all on your own. You have to include it usually in your head.inc file if you are using Joss tutorial as your starting point. The head.inc usually include all the meta data from the head section and there you can add these lines of code. If you are using Bootstrap css and js files I would prefer to load those files from a cdn (fe jsdelivr or Bootstrap CDN) instead from local copies. Best regards Jürgen

@loukote, has someone already said to you that you should grab a template, give it a document, tag and description fields? As addition to @Robin S, If you don't need to display those single document pages to the front, you don't need a template file. Just create a new template in the backend. Additionally to my addition: For those cases, doc repository, category repository, etc, I create two templates without a template file: a parent template (REPO) and a child template (ITEM) The parent template has the following setup: may pages have children: yes can this template be used for new pages: only one! allowed templates for parents: home allowed templates for children: ITEM show in the shortcut menu: no fields: only a title The child template has this one: may pages have children: no can this template be used for new pages: yes allowed templates for parents: REPO show in the shortcut menu: yes fields: a title and all what is individually needed! In the family settings of templates they are linked to each other. After setup the templates and creating the single allowed parent page in the tree, further no one can create repo items on a wrong place, and you can use the short cut dropdown in the admin for creating new entries! I propably do create the templates in two simultaneous opened tabs in my browser, because when creating the first one of them, I can not directly link to the other (as it doesn't exist yet). So I go to a second browser tab, create the other template, link it to the first one and save. After that, I can link the first one to the second one too, and I'm finished. And really, you don't need modules for such things, you simply use PW as it is to setup things individually. Simple, easy and fun! ------------------------

A view month ago, I finished a website for a local Car Dealer. It is based on handcrafted CSS with pocket grid. The dropdown menu is made in CSS, without Javascript. It also has a separate menu for tablets and one for mobile phones. On the intro page is a jssor animation. All background images are made by me. All other content is from the owner. Here are some screenshots how I designed the initial version: http://buescher-gruppe.de/

I feel like this would be the most consistent solution - it sounds like a panel you won't need most of the time, so just activate for when you need it. I'll definitely add this to my list - the more I think about it, the more I am realizing how useful it will be.

Without the big button I would need to switch user to test how the email lands in my inbox Sometimes it's necessary, eg. in case of newsletters. But I can live with the user switch solution, or perhaps toggling it in the panel selector.

Thanks! Inputfields instead textareas is a great relief Features for a mail panel - I will try to think about it but at first I would only need to see what values would be sent, nothing else. And a big button for toggling it on/off

It's just simply the "@" character plus the name, I guess Yes, catching test emails not to reach the customer is a good point. I often solve it adding an if-else condition to set the dev email if logged in as superuser, but it's not that professional. I guess getting email details from WireMail shouldn't be hard. My bigger concern is how to show details for ajax submitted emails - I know Tracy is capable, but they are shown only after page reload, right? So it won't be "live".

Now I found out that the Tags get saved for me also under PW 3, but the form fields (Tags, Descriptions) got not populated via AJAX, so when the page finally gots saved in the page editor, the previously saved values get blanked out again. I HAVE USED THE WRONG HOOK! Damn! It has to be addHookBefore and not addHookAfter. I changed the code in the first post so that it now is working with PW 2 and PW 3. Sorry for the confusion. (I copied the function out of an old module into a $wire->hook for site/ready.php. Hereby I must have accidently changed to the wrong hook event. Damn!)

adrian, what do you think about adding a regex field so that everybody can decide on its own what to exclude? i would leave the textarea (or textfield) for easy exclusion as they are but before adding lots of custom options (also scan site modules, also scan this, also scan that...) a simple regex would be more versatile. and every module developer should be familiar with regex i'm using vagrant together with mailcatcher so i thought i have no need for this. but sometimes i make little changes on live sites and there such a feature could come in handy... sometimes clients want me to do little changes to some of their forms. right now i do such changes live and just do a test submit. that submit triggers a regular mail to the client. it would definitively be better to save the client from receiving some "testbooking xyz" mails so on a second glance i would support thinking about such a feature. this would be similar to the concept of switching templates, if i understand it right, @tpr? edit: how can i mention someone in my post like @tpr?

if(!$pages->get("name={$item_id}")->id) { // create new page } Although you probably want to add other limiters to the selector, like a parent page or template.

Hey, Sorry to hear. Most hosting companies will tell you that the system is running fine (developers: it's the system. operations: it's the application). Have you looked into the server logs by apache or mysql? Ask the hosting provider how they know it is being caused by ProcessWire. Is there enough ram?

Now, that's some nice first post to have in the forums, so first of all welcome here. I just wanted to add a word of caution here. The export functionality should work well for core fieldtypes, but 3rd party fieldtypes might not export/import their settings correctly. Especially for more complex (db-wise) fieldtypes like Table or maybe Matrix it's often not so simple to export to a text format. E.g. FieldtypeOptions didn't export it's options for quite some time. Also I'd be cautious with calling modules discontinued, which is, at least for my module, not the truth. Not seeing a weekly changelog is not necessarily a bad thing.

Ok. // code snippet that belongs into the site/ready.php file: // a hook that reads IPTC keywords on images upload and populates them into the images tags field $wire->addHookBefore("InputfieldFile::fileAdded", function(HookEvent $event) { $inputfield = $event->object; // handle to the image field if(!$inputfield instanceof InputfieldImage) { // we need an images field, not a file field return; // early return } if(version_compare(wire('config')->version, '2.8.0', '<')) { $p = $inputfield->value['page']; // get the page, PW < 2.8 } else { $p = $inputfield->attributes['value']->page; // get the page, PW >= 2.8 | 3.0 (or only from 3.0.17+ ??) } $image = $event->argumentsByName('pagefile'); // get the image // check for IPTC data $additionalInfo = array(); $info = @getimagesize($image->filename, $additionalInfo); // read image markers if($info !== false && is_array($additionalInfo) && isset($additionalInfo['APP13'])) { // APP13 is the IPTC marker $iptc = iptcparse($additionalInfo['APP13']); // IPTC field 025 = keywords collection if(is_array($iptc) && isset($iptc['2#025']) && is_array($iptc['2#025']) && count($iptc['2#025']) > 0) { $tags = array(); foreach($iptc['2#025'] as $k => $v) { if(empty($v)) continue; $tags[] = trim(strtolower($v)); } $p->get($inputfield->name)->trackChange('tags'); // prepare page to keep track for changes $image->tags = implode(' ', $tags); // add the tags list as string $p->save($inputfield->name); // save the page images field } } }); EDIT: code was modified to detect $page also with PW version >= 2.8 | 3.0 EDIT 2: Now it is working for all PW versions again. Had have the wrong HookEvent used here (addHokkAfter, but must be: addHookBefore!)

http://modules.processwire.com/modules/fieldtype-runtime-markup/

@Macrura - just to follow up, I have committed that change - now when you save the module config settings in the backend, the list of panels is reset to the permanent list in those config settings - ie, the Sticky list of panels is Reset. Hope that helps to avoid confusion / problems for others also.

Sorry it is proving slow for some (maybe all of you guys). Wish I was seeing the problems here so I could debug. Does anyone have a live server that is running slow that they'd be willing to give me access to so I can take a look? I'd really like to get this sorted out so no-one feels the need to have an on/off toggle. Are any of you running xdebug? Does disabling it completely make a difference?

I was hoping that was the issue - it certainly loads very quickly for me here. If you ever do find some time to investigate where the problem might be, I'd appreciate it.

Have made some updates to ALIF: 1.1.0 fixed a bug in method sanitizeColor() 1.1.1 added detection and a toggle button for TracyDebugger (enable/disable) 1.1.2 more security for User-Switcher, (stays in for cases, where TracyDebugger isn't available) http://modules.processwire.com/modules/admin-links-in-frontend/

$page->getLanguages() was introduced in PW 3.0.21 (2.8.21). Please check your ProcessWire Version.

@Travo: Thanks for the PR, I applied it to the develop and master branch. If you want to use the module with ProcessWire 3.x, you have to checkout the feature/devns branch of the module.

Sounds like you just need a page field that is linked to the users template. Let us know if you need any help setting it up. These settings for the page field should do the trick - in particular note the Label Field set to "name". Of course if you want checkboxes change ASM Select to checkboxes. It really depends on how many users there are and how many will likely be selected as to which will be better.

Correct me if I'm wrong, but what Google doesn't like are 302s. 301s aren't themselves bad, but can be less helpful to pagerank when stacked. I don't agree with the broad statements of the linked article. A properly used 301 is in fact a great thing for SEO. But also something to be careful with if you want to maximize the value of it. My experience has been that proper use of 301s is one thing that separates the good SEOs from the unknowing ones. They enable you to relocate URLs in a manner Google will transfer pagerank through. They also enable you to ensure people are always arriving at a consistent URL, thereby making it extremely likely that people will link to you in a consistent manner. Lack of properly used 301s increases the odds of diluted pagerank and duplicate content penalties. When someone loads domain.com in their browser and it 301s to just www.domain.com (or the opposite), thats a good thing. When someone types www.domain.com/about-us in their browser and it 301s to www.domain.com/about-us/, that's a good thing. When you have an old About Us link at domain.com/page.php?id=123 that 301s to www.domain.com/about-us/, that's a good thing. This is all good for SEO and good for the users. If this is consistent and stays that way, the external links that you build up over time will also be consistent. The pagerank that you accumulate over time will be maximized, not diluted. And what rare external links that point to content at an inconsistent URL will be identified as such by Google while still transferring pagerank. Where benefit starts getting lost is when you use 301s in a manner that sends it through several paths. My understanding is that Google does dilute pagerank somewhat the more 301s it has to go through in order to meet a request. Example: link points to domain.com/page.php?id=123, which redirects to www.domain.com/page.php?id=123 which redirects to www.domain.com/about-us which then redirects to www.domain.com/about-us/. The user still gets to the right place (good) but the pagerank value of the link that was pointing to domain.com/page.php?id=123 has been diluted to some extent (though don't know how much). Meaning, lost potential, but certainly better than a 404. A smart SEO keeps tabs on this stuff and corrects the first 301 to redirect to the proper URL rather than having to go through further unnecessary 301s. Pagerank potential gets maximized rather than diluted. The use of a slash vs. non-slash shouldn't be a factor for SEO, so long as it's consistent and 301s to the proper version (excluding root level of course). When someone is advising you to always use trailing slashes, I think this is what they are really saying: 1. Always be consistent in how you link to your own pages (regardless of slash standard). Preventing an unnecessary 301 here reduces the chances of some other 301 getting stacked on top of it. It maximizes the value of the link. 2. Standardizing on a trailing slash reduces the chances of having to implement more 301s later (further reducing the chances of a 301 stack). From an SEO standpoint a trailing slash will scale better because there is no functional reason to ever have to change. Whereas, without a trailing slash there is potential for having to change to one in order to accommodate future growth. I keep up with SEO stuff, but it's not my full time job either, so someone correct me if any of this has changed.