Leaderboard

ProcessWire Concatenate Fieldtype Fieldtype that concatenates the values from one or more other fields at runtime. The value can contain additional formatting and/or words as needed, which you define in your Concat field settings. Example Problem: Your system has a first_name and last_name field, and you want to have a separate full_name field composed of first_name and last_name, without redundancy. Solution: You would create a new Concat field, click the details tab, and enter "first_name last_name" (the fields you want to concatenate) in the settings. Other Potential Uses Having a field that combines the value of two or more others, without the redundancy of separately stored data. Defining a custom “label field” for select boxes, like those used with the Page field. Defining a custom label for your Page List that includes your own formatting. Defining an alternate variation of a text field that uses a different text formatter. Considerations The value for this fieldtype is generated at runtime and thus no data is stored in the database. This is good because there is no duplication. However, it also means that you cannot directly query a Concat field from $pages->find(), for example. If you happen to change the name of a field being used in a Concat field, you will have to update the name in your Concat field settings as well. By design, Concat fields do not inherit the text formatters of the fields they concatenate. You define these separately with the Concat field. Because this is a runtime-generated field, there is no Inputfield associated with it. How to Install Install the module by placing FieldtypeConcat.module in /site/modules/. Check for new modules on the Modules screen in the ProcessWire admin. Click Install for the Concat Fieldtype. How to Create a Concat Field Under Setup and Fields create a new field using type Concat. After entering the new field name and label, click Save. Click the Details tab and enter one or more field names. Separate them with whatever spacing and punctuation is appropriate. Optionally choose one or more Text Formatters. If you are not sure which, “HTML Entity Encoder” is a good default to use. Save. Add your new field to one or more Templates. How to access the value of a Concat field This is no different than accessing the value of any other field. If your Concat field has the name “full_name” then you would output its value like this: echo $page->full_name; Download PW Modules Site: http://modules.proce...eldtype-concat/ GitHub: https://github.com/r...FieldtypeConcat

Still another 8 hours here in Holland but best wishes for 2013 to everyone here!

Here's the box on my "desk"*. Still hanging in there. * Actually a salvaged door.

I've dabbled with fetching data from Amazon over the years, but they make it so hard that the few times I've achieved some integration it's been a matter of months before it broke. Part of the problem is that nobody was keeping any of the PHP classes (3rd party, not Amazon) up to date so that put me off. This chap however seems to be doing a marvellous job: https://github.com/Exeu/Amazon-ECS-PHP-Library - demo here: http://amazonecs.pixel-web.org/ I'm actually quite excited about the possibility of looking up products, saving the details locally in ProcessWire (not that you need to, but some sort of local catalogue is always nice and you can have it update prices etc. once or twice a day) and making some money on otherwise not-for-profit sites I've had running around in my head for years now. Interesting stuff!

Hi Pete, Interesting to hear about your use/planned use of one of the Amazon data feeds & PW. I run a little shop listing about 50k items on Amazon at present, some custom coding but mainly using a commercial, closed source, product that I'm now working on replacing as it is too inflexible & expensive for our processes. I've been looking at libraries for the replacement work and found another link you might want to consider if you have pro-merchant account access; this fork of guzzle-aws includes an implementation of Amazon's MWS API. If you don't have a pro merchant account, sticking with the product advertising API feed is free. BTW, the link I've included is for source code that is driving a live shop and seems to have very recent activity. I'm just about to start using it. If you do store data locally just be aware that the terms of service for the APIs have a max cache-time clause to keep price info fresh (24 hours max IIRC.)

Okay, so I did this using nik's example from the other thread and lumped it into a module I've got that interacts with the forum software used here, but for another site. If you're logged into the forums and then leave the forums to browse the site, it checks for a user account in PW with the forum member ID (this is stored in a field as an integer). If it finds one, it logs that user in - no real security issue as 99.9% of people will be a guest and you have to assume staff will be careful - otherwise it creates that user account with the guest role. There's also some other checking for user groups and whether the user has been marked as a spammer. This means that those picked out by the anti-spam measures during registration don't get added as a user on the site and I also added some checks in so that if they turned out to be a spammer later on that their account on the site is trashed as long as they haven't contributed to any pages on the site. Naturally there were a lot more things to check than I first thought, but I'm happy with the solution Now I've paved the way for members to upload and maintain their own files, bookmark useful pages and all sorts of things... but since this wasn't paid work I need to go off and do some of that now Still, it's always nice to have a go at something in ProcessWire every so often just to see how you get on - it's never a question of being able to do it as there's always a way!

This may have been discussed already in the AdminBar thread, but I simply couldn't find it there. Problem seems to be that buildForm method of ProcessPageEdit preserves GET parameter modal by default, while it's otherwise similar cousin in ProcessPageAdd doesn't. I'm just wondering if it would be possible to make these two methods work the same way in this little detail - unless, of course, there's actually a logical reason for this minor inconsistency? Edit: Went ahead and checked what kind of changes this would require. Seems to me that these would be enough: @@ -160,7 +160,7 @@ $form = $this->modules->get('InputfieldForm'); $form->attr('id', 'ProcessPageAdd'); - $form->attr('action', './'); + $form->attr('action', './' . ($this->input->get->modal ? "?modal=1" : '')); $form->attr('method', 'post'); if(is_null($this->template) || !$this->template->noGlobal) { @@ -309,7 +309,7 @@ $this->pages->save($this->page); $this->session->message(sprintf($this->_('Created page %1$s using template: %2$s'), $this->parent->url . $this->page->name, $template->name)); - $this->session->redirect("../edit/?id={$this->page->id}"); + $this->session->redirect("../edit/?id={$this->page->id}" . ($this->input->get->modal ? "&modal=1" : '')); }

delegate profile Basically the home & basic-page template have the same fields. Home » home template Basic-Page » basic-page template Search » search template Widgets » widgets template » status:hidden widget-one, Left, Left widget » widget-one template widget-two, Right, Right widget » widget-two template [*]404 Page Not Found » basic page template » status:hidden [*]Admin Settings » settings template » status:hidden » no file » access:guest view pages Position left or right » settings template » status:hidden » no file » access:guest view pages Left setting template » no file Right setting template » no file [*]Trash defaults.inc The home & basic-page templates include ./include/defaults.inc on top and on the bottom ./includes/main-view.inc. The defaults.inc is the file for common defaults, scripts & variables. Also there's living for commonly used functions & the 12 column classname generate thingy. the 12 column grid On the home & basic-page pages you can check to disable the left & right widgets. If there are no left-widgets to render, then there's no use to render the column at all on the page. The content column then receives the width of the left-column. There are in total 12 columns, say the right column has a width of 3 and the left has a width of 4, then the leftover for the content column is 5. So if there are no left widgets, then the content colum is 9. Those numbers are set to their written equals or set to FALSE. $column['one'] could be FALSE or one, two, three, four, five, etc. $column['two'] could be FALSE or one, two, three, four, five, etc. $column['three'] could be FALSE or one, two, three, four, five, etc. main-view.inc The main-view.inc is the main markup file. In this file I'll check if "template-name.css" & "template-name.js" exists and the append them to the syles & scripts array before I output them with a foreach loop in the page head. This way I know that basic-page.css for example is always the last file & can overwrite previously set styles. The grid uses the same source ordering approach as the zurb foundation grid uses. For mobile it's often a pre that the content column is showed first but on desktop there's plenty space to have a left column first. Thereby I think that Google loves content higher in the source more then if that content is a latecomer. widgets The widgets are just chunks of HTML without <head>, <body> etc. So they can be rendered with the build in Processwire render() function. Nothin' special there. download delegate profile

The problem there is that you've got a Process module that is 'autoload', and Process modules aren't meant to be autoload except in specific circumstances. I'd suggest extending WireData rather than Process. Another issue is that you don't want to add that script to every page like you are doing now. You only want to add it when it's needed. So you'd hook into something like ProcessPageEdit::execute instead. This would ensure that your JS is only loaded when it is needed. public function init() { $this->addHookAfter('ProcessPageEdit::execute', $this, 'addScript'); } public function addScript(HookEvent $event) { $this->config->scripts->add($this->config->urls->AdminJQuery . "adminjquery.js"); }

Thanks for sharing this with us, looks good! Please post to the modules directory (under the site profiles category) when ready. As a small, though not really necessary optimization, that big switch statement might convert nicely to something simpler: $names = array(null, 'one', 'two', 'three', 'four', ...and so on); $column[$key] = $names[$value];

Separation of markup (design) and content - something you do not normally get from a WYSIWYG. So, for example, you might have a template called "paragraph with zoomable image" which would have an input for the content, an input for an image file, and a text-input for an image description. It might render the image with a zoom-button, nice framing, and the image description, and have the paragraph content float neatly around it. Today, your site may use a particular template and markup for that - next year, when your site is redesigned, the markup may change and existing articles can be re-rendered. Same goes if you discover a bug in the markup of a template - all your articles can be re-rendered. For comparison, imagine you discovered your WYSIWYG is generating bad table or image markup. Not easy to back-fix when all of your articles have their content baked into markup. Or imagine you decide articles should use h2-tags instead of h1-tags for the article headline. The arguments for micro-templating in articles essentially are the same as for templating in general - separation of content and markup.

Just in the case that somebody else is looking for a solution to disallow upscaling like i was right now: I just read this thread and thought about using one of the functions above - then i found another thread where some options which were recently added to the PageImage class were discribed: http://processwire.c...tion-questions/ Even cropping direction was added now: http://processwire.c...ons/#entry22535

I was leaning towards Twig, so I took a closer look - I'm not sure what the status of TwigJS is, and I wrote and asked the author. But I don't see any of the standard filters, functions, etc. in the codebase, which looks very, very small... Perhaps Mustache does have what is needed - essentially, a simple JSON view-dictionary gets mapped to a view, which may be enough for simple templates, which may be all that is required for a template-based article editor. Perhaps more complex functionality could (or should) be running exclusively on the server-side anyway, in order to guarantee that it's consistent. There are after all things we can't do on the client-side - for example, uploading and resizing an image has to involve the server-side. Mainly, the point of re-rendering the templates on the client-side is for performance, so that they can be re-rendered in real-time while editing the content/data. The simplicity of Mustache is also appealing in terms of learning curve - developers won't use this, if it involves a lot of proprietary syntax, I think. It has to be easy to set up and must be able to integrate with just about anything. Even if it uses templates and real-time client-side rendering while editing, the eventual output must be HTML, same as if you were using a traditional WYSIWYG editor...

There are a lot of scenarios where i would like to use such a conditional logic - one e.g. could be the following: I want provide a repeater where you can choose an image, set the alignment and an optional linking to the big version of the image or an internal/external link So the repeater fields would be like that: 1. Image field 2. Page field to choose alignments 3. Checkbox if should be linked to bigger image 4. External or internal link The linking to the bigger image will work automatically if the Checkbox is checked - i use the Fancybox for showing the image. If this option is checked, the 4. option does not make any sense - clicking the image cannot work as a link and show up the fancybox at one time. So it wouldn't matter if the client provides that link in option 4 if the conditional logic is set in the template - but to avoid confusion it would be nicer to show this option just if option 3 is not checked, so a conditional logic for the administration would be great. That's correct.

Been reading myself to (always) 3 pages of unread content, so it's a bit late. Nonetheless: congratulations, Ryan!

That's a good example sinnut, but a minor change to make it work: public function afterSave($event) { $page = $event->argumentsByName('page'); // get argument by name, more readable if($page->is(Page::statusUnpublished) || $page->publish_date) return; $page->publish_date = time(); $page->save('publish_date'); } isset() wouldn't work in the previous example as the field exists but is not populated it will always return true. Also $page->of(false) isn't really required as in a module the page has no outputformatting on anyway. To populate the datetime field you'd just give it a timestamp. As the field holds input-outputformatting date formatting it will take that. Not wrong but no need to. If you also need to restrict to certain pages you could add a check for the template before status check. if("article" == $page->template) return;

I don't have coding skills but if you have some this would be an easy module i guess. Something like: /** * * "Set Publish Date" module * */ class SetPublishDate 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' => 'Set Publish Date', 'version' => 001, 'summary' => 'your summary', '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() { // add a hook after the $pages->save $this->pages->addHookAfter('save', $this, 'afterSave'); } public function afterSave($event) { $page = $event->arguments[0]; if($page->is(Page::statusUnpublished) || isset($page->publish_date)) return; $page->of(false); $page->publish_date = date('Y-m-d H:i:s'); // not sure about the date format $page->save('publish_date'); // save only specific field like this? } } Perhaps someone more experienced can help you out

You can simply put the page under admin.

Thanks Ryan! I may even go and get rid of the little tweak I used to get around this . Actually after trying out some not-so-clean solutions for this I finally came up with a really simple one (which mostly seems to be the case with PW anyway). I had an extra page reference in the template I needed this selector for and then a tiny module to set it to parent whenever the page got saved ($page->fake_parent = $page->parent). This way I was able to use a selector like "fake_parent.title|title*=Something" with PW 2.2. +1 for the unit tests! And once the selectors are covered and some kind of a test suite is up, I'm sure there are other parts of the core that would benefit from a little unit test here and there. Just to make it easier for you to refactor whatever needed as you go on building and improving ProcessWire features and versions. While the implications on most used parts of ProcessWire core are revealed pretty fast, there are these must-work-but-would-not-want-to-touch things like localization and internationalization also. Just to name a couple. I'm also willing to help you out with writing those tests if you'd like. Would offer a helping hand with the whole test suite as well, but I'm not experienced enough with that kind of stuff to get it right at once I'm afraid.

Umm, looks like I never actually reported back, sorry. So, no problems with the latest 22 digit version for me so far. I haven't done any systematic testing though, but it's looking good. I compiled a table of the PHP tests run by me and Teppo if there ever happened to rise a need for the information gathered so far (hope not actually). This still remains somewhat a mystery to me, as there does not seem to be any one common factor involved - among the suspected ones that is. I don't actually think it has anything to do with Suhosin (Patch nor Extension), not alone anyway.

Before PW can be installed you have to do some stuff. I often forget 1 or 2 steps. If you run the installer then PW wil tell you exactly what you've done wrong. I love the way you explain it to the developer what he has to do to fix it. ps You can't fix my stupidity :-

You can go to PW's unofficial complementary documents for this http://php.net/manual/en/function.date.php

If you call it in template with $modules->get(..) ? It will get installed (if it's listed but not installed yet) . Would be very surprized if not. Edit: I removed the part in the documentation as it is a general note about ProcessWire modules I think only could be confusing. I tried to rewrite it to mention more details and I screwed

This is a fun question to answer, so thanks for asking it. It really gets down to much of the motivation behind the system. For me it really comes down to time. Time is the most important thing to me. I'm getting old and need to focus on the things that give me more time, and that's what it's all geared around. For others, it's money. But time is money. Either way, you have to ask: "what is saving me time?" That's all you need to know to answer the question. But here's the long version: How much time does it save you to use a template engine vs. PHP API? I would suggest that using a template engine saves you zero time (maybe even costs time) vs. using a clean PHP API like in ProcessWire. Ultimately you are just typing different characters with a template engine, in about the same quantity, to do the same thing (example). Nor is a template engine performing any heavy logic, thinking or processing behind the scenes… it's mainly just substituting one thing for another. It's not saving you any time or mental/logical energy. It's this whole abstraction layer taking up space that isn't contributing anything to the bottom line. So the benefits of a template engine aren't very clear, relative to using something like ProcessWire's API. And I don't think it matters whether you know PHP or not, as the learning curve is identical between PHP and a template engine, for accomplishing the same things. The only difference is that PHP will go much farther, when/if you want it to. Then look at the amount of time it would take you to construct raw DB queries (or through some abstraction layer like ActiveRecord). A simple selector that you write in a few seconds translates to a rather long and complicated SQL query that might have taken quite some time to create and optimize manually. Whether in ProcessWire or somewhere else, to create the SQL query, you would have had to maintain internal knowledge of the database, tables involved, indexes, left and right joins, orders, grouping, limits, security and much more… So I would suggest that ProcessWire's selector syntax is saving HUGE amounts of time (and thus cost) by abstracting away a whole lot of technical details and optimization. At the same time, it's part of a larger system that has also abstracted away the complexities of DB design and optimization, and brought it all into the context and thinking of a website. You don't need to know anything about databases or indexes, or that they even exist. I would also suggest that ProcessWire gives one the impression that they can easily pluck data from anywhere in their site as if it was already in memory… and in the context of a website, not a database. In terms of time and cost savings, is there any comparison between this and a template engine?

It's also possible to add a language pack to the default language, then have english as a secondary.

Change the language for the guest user.