Leaderboard

This week we've got a really nice improvement to ProcessWire's page tree, something that I believe everyone that uses the ProcessWire admin will appreciate. Also a big focus this week was on ProDrafts and wrapping that up so that we can release it and make it available to you. More on both here: https://processwire.com/blog/posts/processwire-3.0.8-brings-smarter-faster-page-tree/

I love fridays.

in my config.php, i setup an empty array for siteSettings like this: $config->siteSettings = array(); then in my ready.php file i'm array merging some values from a settings table (profields table), in the admin like this: $st = $pages->get('/settings/')->settings_table; $settings = array(); foreach($st as $row) { if(!$row->value) continue; if($row->disable == 1) continue; $settings[$row->setting] = $row->value; } $config->siteSettings = array_merge($config->siteSettings, $settings); i'm curious if anyone sees any possible issues with this; it works now and i can access my siteSettings everywhere doing this;

hey, I didn't forget about these issues, just had to finish a client project first. sorry I added the fix for the missing javascript, please pull the develop branch.

Are you sure your template is basic-page (not just another template that includes it, like home)?

We are all falling in love with PW good luck dude

This isn't related to Processwire, but just so the PW community is aware, today we discovered several malicious files in our server (Wordpress environment). The code in the files ultimately allows for the same thing, remote code execution. I'm guessing some security hole allowed an attacker to execute code via a plugin, which wrote a file to www.example.com/dump.php This file contained the following code: http://pastebin.com/dsLZnbCW After deciphering it slightly: http://pastebin.com/NiCe9ftn I then realised it was looking for a post request variable "n59a097" Malicious code was then being sent base64 encoded to this post variable, where it was then being decoded and run through the eval() function. Digital Ocean alerted us of the issue, after our server had been reported to them for sending out spam email. Just a heads up really as to the possibility of security holes allowing simple files to be written, that then allow for remote code execution. I'm sure Processwire is far less a target than Wordpress for these types of exploits but keep an eye out.

Yes, you understand correctly. The reason for this is that ProcessWire was developed to make fine tuned websites, and it doesn't have any control over the markup (with exception to modules), so it all depends on the php code that was written. For a simple example: If you have a field called "phone", and another called "fax", in this order on the backend, you would probably have something like this on the template file: <p id="phone"><?=$page->phone?></p> <p id="fax"><?=$page->fax?></p> As you can see, in that case you only have php in between the <p> tags, and the fields are being called by their names, so changing their order on the admin won't make any difference. In the same way that deleting a field won't remove the surrounding <p> tags, and will probably throw an error since the system is explicitly looking for a field that isn't there. Because of this, PW offers you tools to give this flexibility to editors, like "repeater" fields, or the pro "multiplier" and "table" fields that would allow you to change the order in the admin page, but would have a very different code in the template file: <?php foreach($page->contacts as $contact){ echo "<p id='{$contact->name}'>{$contact->value}</p>" } Of course, all this would have to be accounted for while building the site. My advice is: try to get access to the PHP files, and you will most probably understand easily how to change what you want.

Generally speaking this is true. There can be cases when it is possible to change the order of "objects" on the frontend just by changing the order of pages or repeaters for example, but there aren't any standard ways of implementing features like this for the frontend, since ProcessWire does not dictate any sort of frontend "design patterns / rules". So it all depends on your template files / site profile. You need access to the PHP template files.

Today I want to share a little module that adds 2 additional save buttons with redirect and 1 unpublish button to the page edit. 2 additional save buttons: My intention was that it would be nice if someone saves an article in the backend and will be redirected after saving directly to the frontend page of the article. This module adds 1additional save button at the bottom next to the default save button and 1 at the top. So you can choose if you want to save the article with the default save button or you will save it with the custom save button and you will get redirected to the frontend article. 1 unpublish button: The idea behind this was that I want to disable the setting tab for non superuser. The problem was if I hide it, then non superusers are no longer able to unpublish an article. Therefore this module adds an additional unpublish button at the bottom - the user clicks it and the page will be saved with status unpublished. All pages under the admin section will not be affected of this module. Module is multilingual, so you can set the button texts in all languages. Top view page status published: Bottom view page status published: Bottom view page status unpublished: Here is the code: <?php /** * Adding 2 additional save buttons with redirect to frontend and 1 unpublish button for page edit form. * * ProcessWire 2.x * Copyright (C) 2010 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class CustomPageSaveAndUnpublish extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'Custom page save and unpublish module', 'version' => 1, 'summary' => 'Example for adding 2 additional save buttons with redirect and 1 unpublish button to page edit', 'href' => 'http://www.processwire.com', 'singular' => true, 'autoload' => true ); } /** * Initialize the module * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. * */ public function init() { $this->addHookAfter("ProcessPageEdit::buildForm", $this, "addSaveButton"); $this->addHookAfter("ProcessPageEdit::buildForm", $this, "addUnpublishButton"); // tell processwire that this is a page save if ($this->input->post->submit_save_minor) { $this->input->post->submit_save = 1; // attach hook on page save $this->addHookAfter("Pages::saved", $this, "hookPageSave"); } if ($this->input->post->submit_unpublish) { $this->input->post->submit_save = 1; // attach hook on page save $this->addHookAfter("Pages::saveReady", $this, "hookPageSaveReadyUnpublish"); } } public function hookPageSave($event) { //function to redirect to the frontend after save $page = $event->arguments("page"); if ($this->input->post->submit_save_minor) { // this will get saved after this saveReady hook so no need to save here $pageid = $page->id; $goto = wire("pages")->get("id=$pageid")->url; //get url of frontend article wire("session")->redirect($goto); } } public function hookPageSaveReadyUnpublish($event) { //function to change the status to unpublished $page = $event->arguments("page"); $status = $page->status; $unpublishmessage = __("Status of the page is set to unpublished"); if ($this->input->post->submit_unpublish) { if ($status == 1) { $page->status = "2049"; $this->message($unpublishmessage); } } } public function addSaveButton($event) { //function to add the 2 additional save button with redirect at the top and at the bottom $page = $event->object->getPage(); $status = $page->status; if (($page->rootParent->id != "2") AND ($status == 1)) { //dont show on all pages which are under the admin section and which are not published $form = $event->return; $buttontext = __("Save and go to page"); // new submit button $f = $f2 = $this->modules->InputfieldSubmit; $f->attr("name", "submit_save_minor"); $f->attr("value", $buttontext); $f2->attr("name", "submit_save_minor"); $f2->attr("value", $buttontext); $f2->class .= ' ui-priority-secondary head_button_clone'; // add submit button after the regular save button only if page is published $form->insertAfter($f, $form->get("submit_save")); $form->insertAfter($f2, $form->get("submit_save")); } } public function addUnpublishButton($event) { //function to add the unpublish button at the bottom if page has status published $page = $event->object->getPage(); if ($page->rootParent->id != 2) { //dont show on all pages which are under the admin and dont show the button under the delete tab $form = $event->return; $unpublishbuttontext = __("Unpublish"); // new submit button $f = $this->modules->InputfieldSubmit; $f->attr("name", "submit_unpublish"); $f->attr("value", $unpublishbuttontext); // add unpublish button after the save button if ($page->status == 1) { $form->insertAfter($f, $form->get("submit_save")); } } } } Everybody who is interested can download the modul here: CustomPageSaveAndUnpublish.zip Best regards Jürgen

Hi. I have a setup that sends an email to all users that have subscribed to a category. When a post i published in a category, emails needs to be sent to all those users. For instance, I have 3 user subscribed, so 3 emails should be sent. However, 6 emails are sent and some of the emails are sent to 2 and 3 person at the same time. Please see attached file for what I mean. if( $page->template == "post" && !$page->isTrash() ){ if( $page->id && $page->isChanged( 'status' ) && !$page->is( Page::statusUnpublished ) ) { $from = wire('config')->adminEmail; foreach( wire( 'users' )->find( "roles=partner, location=$page->location, branch=$page->branch" ) as $user_data ){ $mail = wireMail(); $mail->to( array( $user_data->email => $user_data->contact_name ) ); $mail->from( $from, 'My Company' ); $mail->subject( 'Hi '.$user_data->contact_name.'<br>My subject' ); $mail->bodyHTML( 'My message' ); $mail->send(); } } }

You could also add a custom api variable like that. $this->wire('variableName', $obj); In your case it's both config, but if you're adding something different this might even be more appropriate.

Hey Ryan, I saw your recent commits to the ImageSizer and was wondering if you could also add the ability to provide a custom center value (x, y) to the ImageSizer? Like: setCropping(array('30%', '40%')) or setCropping(array('200px', '300px')) Sometimes you know exactly what the most important part of a uploaded image is. And this could also come in handy when developing a InputFieldImage module where the user can click on a image in the page editor to define his own cropping center (or focus point). Most images have a certain point in a image that is most important (like a human face) and should always be visible in crops. Greetings, Niek

Page tree improvement also works with Reno theme, thanks!

I think I just modified the ImageExtra module to add it there. Have a go and if you are still having trouble I'll take a closer look.

Greetings Congomonster, This will work! You need to incorporate this plugin (or one like it), into your site's existing code for handling file uploads. So you first build the form to handle file uploads, then add the plugin to target the file-upload field. Take a look at these discussions on file-uploads in ProcessWire forms: https://processwire.com/talk/topic/3105-create-pages-with-file-upload-field-via-api/ https://gist.github.com/somatonic/5236008 Thanks, Matthew

Hi @kixe I know @kongondo or others will probably be better able to help you but I just wanted to say that the good news is that: is incorrect as far as my experience goes—I just installed it on a fresh PW v2.7.3 and it worked perfectly, no errors. To begin to help, perhaps, check you have debug turned on in config.php `$config->debug = true;`, then there is this post. Sorry if you have already done this and good luck; it's worth it, the @kongondo's Module(s) for the blog make a very professional, complete solution. I was greatly impressed when I tried it.

ok is the installation in a subfolder ? e.g. www.yourdomain.com/ <- index.php // index of pw or www.yourdoimain.com/subfolder/index.php //subfolder is the name of your folder Than you have to change to # RewriteBase / RewriteBase /subolder/ # RewriteBase /~user/

Yup... On a sidenote: The wp-admin Wordpress template / code / PHP editor is by itself a huge security-risk. I would immediately uninstall it.

After so many times for so long, being in the news being compromised makes you wonder if wordpress is still worth anyones time and effort.

Hello, How do you add "InputfieldPageListSelect.min.js" to the module to fix the 0 issue with the link field? Ive tried hooking into the "InputfieldPageListSelect::render" but couldnt get it to work.

@Nukro: What you have so far looks good to me. Your question with the user registration is a valid one, and re-reading my post I found that I left out a step (I was working on our intranet site at the moment where I always have the user password available due to http basic auth, but that's not a given). Thankfully, the scenario gets a little less complicated if each user only needs to see their own passwords. Basically, yes, you need to populate your user's key in the registration (or password change) step. The flow should look like this: 1) User logs in and PW checks if the key in the user template is already populated 2a) If not, create one, encrypt it with the hash of the user's password and store it 2b) If yes, decrypt it using the password hash Now you have the unencrypted key in memory. But you probably don't want the user to have to enter their password every time they view a stored login (or you'd be as good as done here). So, to be able to use the key while the user stays logged in, you need to store it in a way that it can be decrypted without giving the password. The best option for that is session storage. Thus the next steps are: 3) Create a random key (session key) and store it in a session cookie (lifetime 0) 4) Encrypt the user's key using that session key and store it in the user's session 5) Now, with every consecutive visit while logged in, you can read the encrypted real key from the session and decrypt it using the session key in the cookie Even though the encrypted key is stored in the session, it's at no time saved in plain text. 6) Make sure that if a user changes their password, they need to give both their old and new password and re-encryped and store the key again. You have only one question left now: do you need to add protection against password loss? If yes, it gets a little more involved (though not awfully so). You can add a recovery mechanism like this: - Create a public/private key pair for the "recovery agent" that is long enough to asymetrically encrypt the user's key. Keep the private key out of the site (store it in a safe place where you find it again) and make the public key accessible to your code - In steps 2a and 6, also encrypt the user's key with the recovery agent's public key (let's call the result the backup key) and store it somewhere (e.g. another hidden field in the user template) - Create a password reset form where the admin/recovery agent can re-set the user's passwords and enter the private key. Now, when a user loses their password, the following steps happen: - When the admin/recovery agent assigns the new password, decrypt the backup key using the private key, re-encrypt it with the user's password hash and store it just like in steps 2a and 6 - You best make sure that the user changes their password again. Now the regular mechanism of step 6 works again

I Don't see any issue here. It's IMO a good way of doing things, doing it 'all the time'.

I just gave the documentation for CloudCannon a read, and I can't agree with you. You still have to think about how you structure it, decide what information to turn into individual fields (editable regions) and how you name them for translation (manually give every editable region a unique data-i18n key) and styling. The example for the navigation with an endless list of if-statements just to decide which link should have the "active" css class set is enough in itself to make me never ever want to use it as a CMS. The "problems with PW" you mentioned are things every developer should always (at least try to) work out in advance before he/she starts working on a site, no matter what platform. Even a static site needs fixed places for pieces of identical semantic value and proper naming of HTML elements for the CSS and JS that is referencing it to work and still make sense after a year. If you encounter things that you always need to do the same way to get started with a website in PW, you can create a site profile, use one of the Exporter modules or write a short script. This is one of the big strengths of PW: to make complex recurring tasks easy.

+1. Clients don't know the difference between baseline and progressive JPEGs, they just upload whatever they've got and then call when it doesn't work.

Managed to get round to this; fully auto-generated and regularly updated ApiGen docs for all currently maintained ProcessWire branches...More info here

You can also install my ProcessPageAdmin module to do this https://github.com/ocorreiododiogo/ProcessHomeAdmin

Thanks, Adrian. The new notifications system will be interesting, but in the meantime I took a break, then found what I was looking for in Notices.php. The answer is: $this->message("This message contains <a href=''>a link</a>", Notice::allowMarkup); The code from Notices.php couldn't be clearer: /** * Flag indicates the notice is allowed to contain markup and won't be automatically entity encoded * * Note: entity encoding is done by the admin theme at output time. * */ const allowMarkup = 32; /** * Create the Notice * * @param string $text * @param int $flags * */ public function __construct($text, $flags = 0) { $this->set('text', $text); $this->set('class', ''); $this->set('timestamp', time()); $this->set('flags', $flags); }

This is by design. and everyone can replicate it by simply setting the amount of memory way to small for such large images on his server. So, the error message in the first example isn't that lucky because you see the error from the derivative image (admin thumbnail 0x100) what could not be created from the way to large original image that should be scaled down to a max-size. If you have a look into the original image (open it in a simple plain text editor!) you will see that it contains something like: whereas the 0x100 thumb contains: @Ryan: Maybe we need to display the error from original image too so that it is more clear what was going on? So, but in your second example you can already read it by yourself: not enough memory to load/resize Imagerendering with the GD-lib needs minimum ram memory 2 - 2.5 times of the uncompressed image! If you load to large images into memory GD/PHP crashes with a not catchable fatal error. PW since version 2.5 does look ahead to available memory at runtime before loading images into memory. This way it saves you from crashes! I like how it works. Great job @Ryan! Simple calculation example with your image: width x height x colorchannels = memory bytes 4.608 x 3.456 x 3 = 47.775.744 - just to load one of those images into memory (togehther with rest of PW) you need 60MB ram! - and if you want to manipulate / resize it you need 47.775.774 x 2.3 = 109.884.211. Do you have a minimum of 128MB memory available for PHP? No, you need to bump it up. I recommend setting it higher in available server configuration panels, php.ini file or in the .htaccess: <IfModule mod_php5.c> php_value memory_limit 256M </IfModule> But you should not transmit images 4 times larger than the largest needed display size. (Denk an unsere Umwelt und an unsere Kinder die diese auch noch brauchen!) g-translate: (Remember our environment and our children also need this yet)

Several templates can have the same fieldgroup. Say you build a site for a greengrocer, and you want to sell fruit. You want to have different templates for apples pears and oranges, but don't need different fields, then you could share 1 fieldgroup with the apples pears and oranges templates. This way you could search $pages->find('template=apples') and find only apples, but use the same logic for pears and oranges. It could save you time & extra logic. When you delete a template with the API, be sure to delete the fieldgroup to, if it is the last template that uses the fieldgroup.

// via field settings $field = $fields->get("title"); echo "width:" . $field->columnWidth; // via template context $tpl = $templates->get("basic-page"); $field = $tpl->fieldgroup->getField("title", true); // true for template context echo "width:" . $field->columnWidth; https://gist.github.com/somatonic/8323844

I think that URLs will be relative to the requested URL? So if the JS is loaded on page /contact-us/ then the code snippet above would be looking for /contact-us/img/arrow_up.png, which would be incorrect. One way you can get around this is to let PW populate them for you. In your document <head>, add this before any other <script> calls: <script> var rootUrl = '<?=$config->urls->root?>'; var templatesUrl = '<?=$config->urls->templates?>'; </script> Then you'd be able to do this: .scrollUp({location:"right",image_src: templatesUrl + "js/img/arrow_up.png",wait:100,time:300});