Leaderboard

https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=64049

I would create the download section first - arrange them using categories, tags or the tree - whatever makes sense for the site structure and content. Then create a new Page reference field which will allow the selection of videos from the download area, which you can then add to your product templates. This means there is no messing around with TinyMCE (which could be an administrative nightmare to maintain) and you will have complete control over the output/markup of the video listings.

upgrade.php is not a ProcessWire file. I'm guessing maybe it was a leftover from a previous WP or Joomla install? It sounds like it could be related to the exploit you experienced, but be careful not to assume it ends there. ProcessWire's core does not have very many input opportunities on the front-end of your site. Actually, the URL itself is really the only input ProcessWire deals with on the front-end, and that is validated by the htaccess before being sent to PW, and then thoroughly sanitized then validated again by the core. As a result, it's unlikely for ProcessWire itself to be exploited in the same ways that some other CMSs might be, simply because there are a lack of input opportunities to a guest visitor. What ProcessWire does instead is give you an API that lets you control all the aspects of when user input results in something output. If there were to be an exploit on a particular PW site, it would be much more likely to be the result of the code unique to that site, or a 3rd party module, rather than PW itself. If you were dealing with a site that had other software running, either presently or in the past (perhaps WP powering a blog alongside) then it'd be much more likely for that to be the source of the issue than PW. In fairness to WP, most exploits have to do with 3rd party WP plugins or themes and not WP itself. WP and Joomla are also much larger targets than PW, so they are usually broken into with automated scripts rather than actual people sitting at their computer. When you've got a site that you know has been broken into at the filesystem level (like yours might have been), it's unusual for it to be limited to just one file. There are usually backdoors built elsewhere. Even if the site is fixed for the moment, it's good to still think of everything as tainted until proven otherwise. I'm not necessarily a fan of restoring from a backup in this case, unless you know for certain that the backup itself does not contain the exploit. Sometimes a backdoor will be present for months before taken advantage of. If you had Joomla running on this server a long time ago, the exploit may have originated there and simply been hidden somewhere on the file system. The first thing you'd want to do is remove any other software installed on the server that doesn't need to be there–old copies of WP, Joomla, etc., or files leftover by them. If you aren't certain, then just move it to a non web accessible quarantine directory. For your ProcessWire site, you don't need anything in your web root directory except for: /wire/, /site/, /index.php and .htaccess. Remove your entire /wire/ directory and put in a new fresh copy, as well as your /index.php and /.htaccess file. Basically do the same thing you would do if performing an upgrade. In /site/modules/ you may have some 3rd party modules installed. Replace each of the directories in /site/modules/ with fresh copies. This is the same thing you'd do if upgrading those modules. That essentially leaves /site/ and everything in it to analyze. If the hack originated from an automated script targeting DrumlaPress, chances are it left your PW installation alone, but you never know–it might have gone after every single PHP and JS file it could find on the file system. You'll want to look for anything unusual in your /site/templates/*.php files and /site/config.php file. By unusual, I mean anything that you didn't put there. Start by looking at the beginning and ending of each file. Red flags are usually extra <script> statements, base64 function calls, exec function calls, extra JS attributes on markup elements that you didn't put there (like onclick), include or require statements with variable names in them or referencing files you don't recognize. Also consider that new directories may have been introduced anywhere. I would download a copy of your entire /site/ structure and analyze it locally, looking for any extra files or directories that you didn't put there. Also be on the lookout for extra .htaccess files, and give them a close look if you find any. Meaning, you'll need to make sure you are seeing hidden files (those preceded with a period). Compare your /site/ structure to a /site-default/ structure as included with a new copy of PW. Once you've cleaned your /site/ directory or at least verified that it's clean, make a good backup of your site so that you've got a known clean starting point (hopefully). Open a browser to your site with Chrome and go to View > Developer > Developer Tools. Click to the "Network" tab. Reload the page. Look for any offsite requests that you don't recognize. That may reveal something hidden that might still need to be cleaned, but hopefully not. Now click to the "Elements" tab. This shows the post-JS markup of your site. Look for any generated elements that you don't recognize, especially at the end or beginning. This again can reveal extras that have been added into your page by an exploit. Lastly (or maybe firstly?), take a look at your file permissions. If on a shared host, you want to be certain that your files aren't readable or writable to other users on the same server. Especially your /site/config.php file, and your /site/assets/ directory (and everything below). What permissions are ideal here depend on the web host and what type of PHP they are running, so it's best to inquire with them on how you can have files writable to your website that aren't writable by other accounts. Btw, I have never seen or heard of a compromised PW installation, regardless of what other compromised software was running on the server. I have seen plenty of compromised WP installations that had PW running alongside them. Thankfully, the PW installation has always been left alone, with the exploit limited to the WP installation. But it's best to go into these things assuming everything on the server is tainted, so always play it safe.

I would use "find("!user_activation=0");" instead of $=, if it's a integer or checkbox field.

@peterfoeng: this is great. I have seen that you already sent a pull request that should solve one or two issues. (I haven't tried it yet) The development and maintaining of this is open to all but write access to the repo should be limited to few people only I think. In the past Owzim and I have successfully and efficiently colaborated on some enhancements to the thumbnails module and he has good skills in js and css. Therefor I really would like if he join in here. Regardless of this, any help and contribution is highly appreciated. The best way to go, (I think), would be to do this for the current module: - PullRequest from PeterFoeng And after that we should start a fork with: 1) creating the clear naming convention for this module, like Antti has suggested (and Owzim). 2) Actually pending is an enhancement to the images naming scheme that supports custom-suffixes and assistant method(s) to use that. After we know how it is finally implemented in Pageimage we will use this in the new fork of Thumbnails module. That allows us to strip out hooks and code for deleting variations. (this is delegated to the core pageimage by the custom-suffixes) 3) Also pending is an enhancement to the imagesizer that allow a "crop before resize" manipulation with individual and exact coordinates. (The default behave is first resize and crop after) With this supported, the thumbnails module can delegate the complete imagemanipulation to the ImageSizer. This will allow to further deleagte it to any dropped in PageimageSizerModule without any additional interaction. If you decide to use another image rendering engine (currently only the PageimageSizerImagick is available) you simply install this and it will work for all image variations, regardless if they are requested by the core Imagesizer or by the thumbnails module or by any other future third party module. fixing known issues: 4) I have tried to use the settings with 0, but it doesn't work for me with height set to 0. I tried these settings: thumb1, 0, 200 thumb2, 200, 0 The first works as expected, the second doesn't. It always displays the full image and when I open the crop-page I do not get an Rectangle. 5) When setup thumbs bound to templates, uploading a new image to a site with one of these templates creates also variations that are only bound to other templates 6) When upscaling is set to false in the config.php, it isn't respected by the CropRectangle. For example if there is a setting 200,300 and upscaling is set to false, the rectangle should not go smaller than 200x300, because if a smaller rectangle is allowed, the resulting image would need to be upscaled, what isn't allowed! Make the CropRectangle respect / reflect this. After these steps we should try to implement some of the requests already posted here: - thumbnails admin Grid View - support for Retina Variation @2x - copy cropped variation to other field(s) / using it within RTEs - and others that I haven't recognized yet

Continuing from my previous post in this thread about some selector enhancements available on the dev branch, we've got a couple more advanced options for use in selectors in case anyone is interested: OR-groups These let you specify multiple expressions and only one of them has to match in order for the selector to match. It's a way of saying "either this has to match OR that has to match". This is useful because selectors always assumed AND – meaning everything has to match. While you have always been able to use the pipe "|" to specify ORs for fields or values or both, the scope of it was just that field=value statement only. Now we have something new called OR-groups. These let you create multiple selector groups and only one of them has to match. You can specify OR-groups by surrounding selectors in parenthesis. An example demonstrates it best. Lets say that we wanted to find all "product" pages that were in stock, and either in a featured date range, or had a highlighted checkbox checked. Previously we would do like this with two separate find operations: $items = $pages->find("template=product, stock>0, featured_from<=today, featured_to>=today"); $items->add($pages->find("template=product, stock>0, highlighted=1")); Now we can do it in one find operation: $items = $pages->find("template=product, stock>0, (featured_from<=today, featured_to>=today), (highlighted=1)"); Above are two selectors surrounded in parenthesis. Only one of them has to match. You can specify as many of them as you want. This type of OR expression is something you couldn't previously do with selectors. Think of the parenthesis as a way of saying "this is optional". But of course, at least one of your parenthesized selectors has to match in order for the full selector to match. I'm guessing the above usage probably covers 99% of the situations where you might need it. But lets say that you want to have different combinations of OR expressions. You can create named groups that OR with each-other by specifying: foo=(selector1), bar=(selector2), foo=(selector3), bar=(selector4) In the above you'd replace "foo" and "bar" with names of your choice. And you'd replace the "selector" with any selector strings. Those foo/bar names aren't referring to fields, instead they are just named groups that you can name however you want. In that selector, at least one of the "foo" named selectors would have to match, and at least one of the "bar" named selectors would have to match. If you didn't use the foo/bar named groups here (but still used the parenthesis), then only one of the 4 selectors would be required to match. Sub-selectors Some of you are already familiar with these because it was committed to the dev branch a couple weeks ago (and I think may have been outlined elsewhere in the forums). Sub-selectors let you put a selector within a selector, enabling you to perform more complex matches that used to require you to use separate API calls. These can be used on the 'id' property of any field that maps to a page. The 'id' property is assumed when referring to a page reference or a parent, so it's not necessary to specify it unless you want to, i.e. "field" and "field.id" mean the same thing in this case. Sub-selectors are specified between [square brackets]. For example, lets say we are matching products and our product template has a "company" page field. Each company also has it's own page field where all the company locations are identified. Lets say we want to find all products that are made by a company that has more than 5 locations and at least one of those locations has "Finland" in the title. Previously we would have had to do it like this: $companies = $pages->find("template=company, locations>5, locations.title%=Finland"); $items = $pages->find("template=product, company=$companies"); That's easy enough. But now it's even simpler, as you can do it in one operation: $items = $pages->find("template=product, company=[locations>5, locations.title%=Finland]"); When you've got a "field=[value]" selector, any properties you refer to in "[value]" assume the "field", so "locations" above is referring to a property of the "company" field.

Hi, After reading this thread, I decided to make a module that helps generating PDF files of ProcessWire pages. GitHub: https://github.com/wanze/Pages2Pdf Modules Directory: http://modules.processwire.com/modules/pages2-pdf/ This module uses the mPDF library to generate the PDF files. It has fully UTF-8 and basic HTML/CSS support for rendering the PDF files. The output is customizable with ProcessWire templates. Example I've enabled generating PDF files for the skyscraper template of ryans Skyscrapers-profile with a template that outputs the data in a table along with the body text and the images: one-atlantic-center-pdf-4177.pdf Please take a look at the README on GitHub for instructions and further information/examples. Cheers

Hello! About the same time Hari KT asked about "Remember Me" functionality, I identified this as a feature I wanted to implement in some sites under development. Having done this twice before (in CodeIgniter) and based on previous research, I decided to build a ProcessWire module to provide this feature. So far, I have developed and tested this on ProcessWire 2.3. I would welcome any feedback, comments, suggestions and problems from people who are keen to use this. To re-iterate the readme, this module allows users to remain logged in across browser sessions. The module can operate in two ways:Automatically. No code changes, but users do not have a choice. Manually. The module must be called from a site's custom code. Options can be changed in the module configuration page. Enable fingerprinting (IP address and User Agent) as an additional security check. Limit the persistent login functionality by role. Set the name and age of the cookie. Sets an identifier in the session when a user is logged in via a persistent login cookie. This should be used to control access to sensitive information and actions within a site's custom code. Clears login tokens when a potential theft has been identified. Updated: LoginPersist on GitHub

Template Cache and $page->render($options) If you ever use the $page->render() to render out partials (of another page using its template file) and use template cache for the pages you're going to render and the page where you render it, it will create a cachefile. So if you go to that previously rendered and cached page, it will render that partial. If the page is accessed before a cache is created, it will cache this one and render that in as the partial, so kinda turned around. Funny effect. And many mmms and oaaahhhs To get a better understanding what's happening read on. Simple example code from a list page to render partials of articles (likely) // from the list pages template $markup = ''; foreach($products as $key => $child) { $markup .= "<dl>"; $markup .= $child->render(array('isOverview' => true, 'class' => $class)); $markup .= "</dl>"; } echo $markup; And in the template of the article // in article template file if(isset($options['isOverview']) && $options['isOverview'] == true) { // render small partial $class = $options['class']; $markup = "<dd class='$class'> <h4>$page->title</h4> <p>$page->summary</p> <a href='$page->url'>details</a> </dd>"; } else { // render complete article $markup = "<div class='product-details'> <h1>$page->title</h1> $page->body </div>"; } // output echo $markup; So now the render call $markup .= $child->render( array('isOverview' => true, 'class' => $class) ); in the list template will cache the page it renders (the small view of it). Thus if you access the page directly it will serve the cached small view of it. Ups. Solutions This is without specifying a different template file in the first argument in the render(). The effect doesn't happen when you, let's say create a new template file (ie article-small.php) and use that to render the page. Since this new template file is not connected to the template in PW it also has no cache for that render. To show what I mean is the following with the first argument the file you want the view to render. $markup .= $child->render("product-small.php", array("isOverview" => true, "class" => $class)); Still following me? Ok there's also another method to not allow a cache file to be created. There's a default options set in the render() in PW. Bingo! allowCache is what we can also use. $markup .= $child->render("product-small.php", array( "allowCache" => false, "isOverview" => true, "class" => $class )); And everything's back to normal. Just wanted to write down a little thing, as I stumbled over this recently, to scatter some keywords about this here . I think this isn't really documented somewhere but I thought it was maybe mentioned by Ryan in a thread about when he added this feature: http://processwire.com/talk/topic/3145-multiple-views-for-templates/page-2?hl=%2Brender+%2Bcaller#entry32876. Edit: Zaaakkkk and it's in Google 9 minutes !

Super Smartypants is a ProcessWire textformatter module which adds support for languages. It also allows you to set the different Smartypants Typographer parser attributes to customize which rules apply and fixes some bugs. Super Smartypants requires the language module. Usage After installation, add /site/modules/TextformatterSuperSmartypants/smartypants.php to your language translations. To enable Super Smartypants for a language, set the Smartypants attributes field to 1 (or see below for details), otherwise to disable leave the field empty. Change default strings according to your masterful typographic knowledge. Documentation and download : https://github.com/plauclair/SuperSmartypants

Hi, I'm writing a few modules that use Oauth rather than your usual API keys. I need to store the token after the user is returned to the backend. I can figure out how to make the module configurable using the getModuleConfigInputfields class, but is there a way of setting one of these options via the API and having it stored in the DB? Many thanks, Stephen

Try replacing: $users->delete($u); with: $this->users->delete($u); Also, turn on debug mode so you get some error reporting - these should be showing up.

From what I understand, OR-groups are not needed here, since we only want to OR two values in the same field. Selecting login_end=1406930400|1416524400 works, so why doesn’t login_end=0|1416524400? 0 on its own matches empty datetime fields. The SQL error is "not unique table/alias", so that looks more like a bug. LostKobrakai’s solution is the best anyway, though.

Doesn't "template=user, !login_end<=today" work?

Sounds a bit like "collection" might be a Page type field. If that's the case, try something like $page->collection->title (if it's set to contain one Page) or $page->collection->first()->title (if it's set to contain multiple Pages).

Hi, I just found a problem with the html inputfield number in conjunction with floats. If I use the german language pack it changes the value of the input field to "," seperated instead of ".", so the input field doesn't display the value.

I use Chrome as my main browser; and when I need to do account or session based testing I usually head to Incognito mode as well

@Dave, I use Incognito Window for that. I love it because I don't have to start 2 browsers and the Incognito window looks different then the default. Chrome on the mac: [ shift ] + [ command ] + [ n ]

Which version of ProcessWire do you use? A quick look at 2.4.0 and newest dev version shows translateable strings for everything that's still english in your screenshot.

Thanks Dave. That's not something that I've looked at specifically - I copied the parameter values from elsewhere in ProcessWire - and the domain one is just set to null. setcookie($this->get('cookieName'), $value, $expires, '/', null, false, true); I haven't been caught out by this issue as I've always set up individual hosts for each site I work on; but definitely something to be aware of. It would be relatively easy to add a configuration field to the module for a user-specified cookie domain though, if it was required

Just as a by-the-way, don't waste your time using Chrome to test this on localhost - chrome.cookies fails for localhost domains, because it won't work (Chrome bug/'feature', not this module).

Hi Craig thanks! Thats exactly how I am going to do this.

Brilliant; 3 days later i have full functionallity... login using ryan's script https://processwire....tor-login-form/ page edit using soma's modal trick https://processwire.com/talk/topic/2382-processwire-setup-and-front-end-editing-made-easy/ access control via http://modules.proce...-edit-per-user/ module and some cool table editing via profields table https://processwire.com/api/modules/profields/table/ 3 days with just a couple of hours a day..

I'm wondering if it would be worthwhile wrapping that declaration in another check, inside the current mod_rewrite check? <IfModule mod_env.c> SetEnv HTTP_MOD_REWRITE On </IfModule>

The quick answer, Regardless of the hack, if you are using shared, VPS or even dedicated server hosting, even ProcessWire can be affected. If the site that you manage is using the same user account and/or on the same virtual/physical server as a compromised WordPress or Joomla site, any compromise can indeed affect the ProcessWire installation. If there are no old/new WordPress or Joomla installations under the situations I described and you are having this problem, then yes there may be an issue with ProcessWire. Please let us know if this is the case, however I doubt if it is, since we would have already seen this occur in other ProcessWire installations worldwide. PHARMA is an old hack, but it doesn't mean it hasn't been updated. Either way, you need to work with the security team at your webhost to identify and mitigate any issues. Please keep us informed on your progress clearing this issue up. Best Regards, Charles

Not really. Identifier in can be any valid label. This, for an example, is entirely valid: <?php echo <<<TEPPO Hello world. TEPPO;

That should not a problem I guess. What about the time to live? If you didn't set it, it is an hour. ( 60 minutes)

Sorry I quickly ready your title and not really the description. It's actually really easy, but I think the instructions here: http://processwire.com/api/fieldtypes/repeaters/ are slightly wrong in that they say to save $page. This works: $socialphoto = $p->social_photo->getNew(); $socialphoto->save(); $socialphoto->date = '2013-05-16'; $socialphoto->image->add('http://localhost/pw/site/apitest/test.jpg'); $socialphoto->pinned = 1; $socialphoto->save(); So the things I changed are: Using $p instead of $page as it's not good practice to overwrite $page as it refers to the current page I am saving $socialphoto and not $page/$p You already figured this out, but you need to save straight after getNew() to be able to add items to the repeater I am using a valid date format - maybe your format will work if that is how you have the field configured - I have never really tested those configs Hope that helps.

$event = new Event(); $event->date = "1979-10-12 00:42:00"; $event->location = "Vogsphere"; $event->notes = "The homeworld of the Vogons"; $page->events->add($event); That's one way to do it, at least. Since $page->events here is events field it returns an instance of EventArray, which in turn can contain multiple Event objects. For the most part EventArray acts just like a PageArray or Pagefiles or any other object extending WireArray. This is just the most basic example of what you can do with it.

I've testing the scheduler and I had this morning a strange behavior for a page I was testing yesterday where only the publish from is filled with a datetime past the current time. The scheduler is set to 2min. I had the page unpublished and tried to see it would get published and this was what I got in the log for this page: It was getting published and then unpublished at the same time... 2013-12-04 10:30:27 guest http://removed/ Published /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 10:30:27. (SchedulePages) 2013-12-04 10:30:27 guest http://removed/ Unpublished /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 10:30:27. (SchedulePages) 2013-12-04 11:01:58 guest http://removed/ Published /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 11:01:58. (SchedulePages) 2013-12-04 11:01:58 guest http://removed/ Unpublished /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 11:01:58. (SchedulePages) Really strange. And I was trying to find out but couldn't. I set the published_until and tested again but seems like it is gone away. I blanked the publish_until again and still couldn't get the behavior as before. I tested with other pages but no luck. BTW I added before all testing, the suggested text fix you mentioned some posts earlier #180 if($p->publish_until <= $currenttime AND $p->publish_until > 1) I'm not sure what was causing it, and hope it's not something that will give surprises later

Thanks Wanze, I managed to get it sorted out. $n = 1; $type = "expense$n"; $desc = "desc$n"; $amount = "amount$n"; $pm = "method$n"; $expenses = $p->travel_expense; // the repeaters foreach ($expenses as $expense){ $rp = $pages->get("id=$expense->id"); // the repeater page we want to update $rp->of(false); // update repeater fields $rp->expense_type = $input->post->$type; $rp->expense_description = $sanitizer->text($input->post->$desc); $rp->expense_amount = filter_var($input->post->$amount,FILTER_SANITIZE_NUMBER_FLOAT,FILTER_FLAG_ALLOW_FRACTION); $rp->payment_method = $input->post->$pm; // save the repeater page $rp->save(); // update counter etc $n++; $type = "expense$n"; $desc = "desc$n"; $amount = "amount$n"; $pm = "method$n"; }

Welcome to the forums Thomas. It's not possible to physically resize an image on another server, but you certainly can resize it with CSS or width and/or height attributes in the <img> tag. But if you want an image you can physically manipulate, then it has to be on a file system that ProcessWire can write to. You can tell ProcessWire to pull an image from another server like this: $page->video_image = 'http://domain.com/path/to/file.jpg'; $page->save(); Once you've got the image in there, you can resize it like in your example. I'm assuming from the non-plural name 'video_image' that you've defined the field to only hold 1 image rather than many. Though the snippet above should work either way. Note you may need to add a $page->of(false); before the code example above if you are executing it from a template file. ProcessWire delivers pages to templates in an output-ready state where entities are encoded and such (something you wouldn't want when saving a page). So you just have to disable output formatting to put the page in a state where it can be saved, otherwise ProcessWire will throw an error. This isn't usually necessary in other API contexts, outside of template files.

To save module config data, put the data you want to save in an array and then call the $modules API var with the saveModuleConfigData function. <?php $data = array( 'something' => 'Well hello there', 'something_else' => 1234, ); $module = 'ModuleClassName'; // can also be instance of module wire('modules')->saveModuleConfigData($module, $data); ProcessWire will automatically set the keys from your configData to the module when it loads, so you don't have to do anything else. As a result, your module could call upon a value like $this->something; and the value would be there. Or if you want, you can add a setConfigData(array $data) function to your module, and it will set the config data to that instead (when the module is loaded). Though I rarely do this. To retrieve a module's config data from another module or elsewhere in the API, you can also use $modules->getModuleConfigData('ModuleClassName'); Use it like this: <?php $data = wire('modules')->getModuleConfigData('ModuleClassName'); echo $data['something']; // displays 'Well hello there' The $data would be the same array that you set in the first example.