Leaderboard

I am working with a designer who's experience lies mostly in print. So, I have written a document explaining the fundamentals of modern adaptive web development. This is not a technical manual, but rather looking at what needs to be considered by the creative designer when coming up with something that a developer can deal with well. Since we have a good assortment of multi-disciplined souls here, would a few of you care to read it and suggest anything I perhaps should add, without making it heavier or much longer? Some of you may find this useful for your own purposes too and you are very welcome to use it. UPDATE I have done a new draft, removing the adaptive idea which kind of got lost as I wrote - the trials of writing an essay off the top of my head with no planning whatsoever! Silly me. It is now called Responsive Websites UPDATE 2 Cleaned up version - the chat about flat icons is now shoved at the end as an after thought Responsive Websites 2.pdf

New line starts after 100%. 33+33+33=99% so the next one tries to fit within that last 1%. But there is not enough space so it floats into a new visible line. Then the "real" new line starts but repeats again. This is just default CSS behavior;) Make two columns 33% and give the third one 34% to fix this. No one will notice the 1% difference.

Hi everyone, I'm glag to introduce pierre-diagnostic.fr. This is the corporate website for a french real estate services agency. It was built with Processwire 2.5.3 and the following modules : AIOM ProcessBatcher Zurb Foundation 5 (wich is a delight to work with) Go Processwire!

Adaptive websites use breakpoints to target for specific viewport widths, while responsive uses percentages for elements to adapt to the width of the container where it lives in. Adaptive and responsive can work nicely together, but the terms aren’t interchangeable.

This with the Textareas in COnfigurable Modules I have tracked down to this line: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/InputfieldWrapper.php#L300 Before this line the content of $ffout looks like: "\n<textarea id=\"Inputfield_textarea-value\" class=\"InputfieldMaxWidth\" name=\"textarea-value\" rows=\"5\">line one\r\nline two\r\nline three\r\n</textarea>" and after processing the preg_replace, $ffout holds "\n\t\t\t<textarea id=\"Inputfield_textarea-value\" class=\"InputfieldMaxWidth\" name=\"textarea-value\" rows=\"5\">line one\r\nline two\r\nline three\r\n\t\t\t</textarea>" I have filed an issue at GitHub: https://github.com/ryancramerdesign/ProcessWire/issues/759

Another month went over and I want to give you a quick update on the lightning.pw project. Thanks so far to all of our users. Bad things first: Yes, we face challenges with our FTP service. The daemon is quite fragile and the only helpful solution is to restart FTP every 60 minutes on the server. We're looking into this issue and are trying other programs at the moment. If you have a problem, just drop an email or tweet us on twitter. After over a month we now have 80 users and 136 sites running. Five of those sites are hosted for free as a demo. The Default profile was used the most, followed close by the blank one. Since we started the service, Ryan has pushed 61 versions of ProcessWire (including updates, dev,stables) to the github repo. With lightning.pw it is easy to always have the latest beta ready and running We were kind of busy with our other student jobs and with the development of some modules you might have heard of.... Anyways, a Dropbox-Sync is on it's way and we will also integrate the snapshot/recover function with the next update. The user defined profiles still have a high priority. We made updates behind the scenes to improve stability and to fix minor issues.

hi pascalKonings my hosting provider solved the error , it was a lighttpd configuration. I was getting the above error every time that a page was using a get ( ?something ) method. Adrian I think that now pw run perfect in lighttpd server I still building the page but everything seams to run smooth

It is cause filter is runtime memory while find is db query.

There is a problem with TV and radio advertising in that all of us who do it always say if we had a longer commercial then we could explain our proposition so much better! But the reality is that the client comes along and says "since you have an extra thirty seconds, here is a ton of copy about my pet dog I want to get in there." When we only have a short commercial, all elements - audio, pictorial, text and so on have to work really hard and keep to the plot. If that is then translated to longer commercials, then you increase the power. if you simply add to it, you reduce the power. I think mobile first thinking is the same. In a way, it is an excuse to make sure all design elements work hard since size and space removes the luxury of "oh, they will get it by the time they get to the bottom of the page." In that respect, the look and feel of the design is part of the content as it not only frames the content, but is part of the brand and the company ethos and image that explains the content.

@jmartsch The title field is actually good as you can use it as a browser title field which can differ from the page title or an ulr pathsegment etc.

Thank you for the module. I'm using it on a site in development as input for publishing times. Discovered no problems so far. All is running smoothly. Have you considered adding optional JS to the field for user friendly input through a time picker like http://jonthornton.github.io/jquery-timepicker/ ?

@organizedfellow I would have done over a dozen EE > PW site moves in the past two years. I have one more to do and that's for a 300+ user artist site. The problem (for me) with EE has always been the upgrade process as well as the need to have itty bitty little extensions to do this and that. If you rely on just one of those extensions and it's not kept up-to-date with the current EE version you're stuffed. And you only find that out once you go through the excruciating upgrade process. To my knowledge EE still doesn't keep it's system files separate from site files. It's a colossal PITA on a big site. I've shown clients the ergonomic differences between EE and PW when it comes to the page tree. They immediately get it compared the convoluted channel and entries system. "Oh you can mix pages with different field sets under one tree? Really?" The EE folk will say, "Yes, but there's the Structure add-on for that." Well then why are you shoehorning EE to work like PW? You may have to mock something up for him on a subdomain as you say. I've done that once or twice at the pitch stage and it was super quick to do. Good luck.

The first thing to do is leave the technology completely out the conversation, even if the client starts asking. Websites are, in the end, marketing and communications tools and it is vital to get the client thinking about the brand, the message, the need and the customer. If I was making a TV commercial, I would not expect the client to ask which recording desk I would be using for the soundtrack, but I would expect him to tell me whether commercial will be aired on cinema as well as television. In above the line advertising, the client wants clear results above anything else and it is worthwhile to encourage the same expectations for their website. Since a website may also involve the client or someone from their organisation working on the site, then it is also important to make the point that the site should also be easy to use. There is not need to say "ProcessWire" is easy to use, since that is meaningless if they don't know what a processwire is, how much to feed it or where you can get one kennelled. So, again, no technology speak, this is about assurances that YOU can fulfill the brief not that the software can. Coming from an old world creative production background, one of the most frustrating things I have found is this huge blurred area between the needs of the brand and the technology needed to get there. I suppose it is because many people in creative roles are also in technology roles, whereas in film production, for instance, the two roles are often separate and have been so traditionally for a hundred years. The client therefore has a clear route: Account Manager -> Creative -> a great big, magical, foggy bit when the technology is handled by people he is not introduced to -> final product to be signed off and paid for. Much better for all concerned

We'll be here with a box of tissues and some kind words. Maybe even some help

I've just posted a Fieldtype and Inputfield module combination that support the use of MySQL time fields in ProcessWire. Ryan's Datetime module is great but I needed something that dealt specifically with times for a scheduling system and this is one of the results. For 24 hour clock format ('HH24MM') you now get a clock-picker pop-up by default... ...but you can inhibit it if you don't want it... Although the input time format is selectable, as this is stored as a MySQL time field, you currently need to specify values in selectors in full "H:MM:SS" format. So if you wanted to get all events starting on or after 9am you'd do something like this... $events = $pages->find("template=events, starts>=9:00:00")->sort("starts"); This is definitely a beta module as I've not tested every single input format yet. Currently does not support negative time-periods or fractions of a second. FieldtypeTime on Github FieldtypeTime in the Module Repository Releases Version 0.2.0: Adds support for the use of this input field in repeaters and repeater matrix types. Version 0.1.0: Adds clock picker.

Just posted a new module to github that simply displays a google calendar in a new calendar page in the Admin interface. It's meant to go hand-in-hand with Ryan's MarkupLoadGcal module. There's really not much else to say about it other than it uses the new module config class so you'll need to be running an up-to-date dev version to be able to use this. Here's a shot of the config page... ...and here's what the calendar page is like... Please note, this module only embeds the calendar; the event you see listed under the calendar in the screenshot above is added by hooking this module's execute() method and extending the output. The hook method uses Ryan's MarkupLoadGcal module to pull events out of the calendar's feed and then appends them under the calendar. ProcessGcalEmbed in the module repository. ProcessGcalEmbed on Github.

This is an inputfield module integrating Trumbowyg WYSIWYG editor into ProcessWire, quickly hacked together after some discussion at the Redactor thread. Trumbowyg is a light-weight alternative to more feature-rich editors, such as CKEditor or TinyMCE. Both this module and Trumbowyg itself are still in alpha state. Customisation options include only a subset of what Trumbowyg provides, more will be added in the near future. Also, link and image features as seen in other RTE modules (TinyMCE and CKEditor) are not implemented yet. The module is available at https://github.com/teppokoivula/InputfieldTrumbowyg.

GitHub: https://github.com/owzim/FieldnameUnprefixer From the README.md: Makes it possible to access prefixed field names without the prefix. Usage Create some prefixed fields and add it to you desired template, for example prefix_myField and otherPrefix_myOtherField. Configure the prefixes, that should be removed in your /site/config.php, like so: $config->FieldnameUnprefixer = array( 'basic-page' => array('prefix_', 'otherPrefix_'), 'home' => array('prefix_', 'otherPrefix_') ); The first array keys are the template names. The Prefixes also can be assigned as a string if it's just a single one: $config->FieldnameUnprefixer = array( 'basic-page' => 'prefix_', 'home' => 'otherPrefix_' ); Now you can access the fields without the prefix, like so: echo $page->myField; echo $page->myOtherField; The unprefixed field names are now also accessible via selectors, but only for already fetched data, since the field is not really in the database: // not $pages->find('myField=something'); // but $pages->find('template.name=basic-page')->filter('myField=something'); Use case Prefixes are sometimes necessary to have fields that behave specific to the template, so you need to create a specific field and namespace it with a prefix, but don't want to access the fields differently on each template. // eeew! $client->client_address; $something->something_address; // yay! $client->address; $something->address; Might be not the ProcessWire-way because data access is abstracted, but I use it, and perhaps some of you find it useful too.

Oh hey, how did I miss this topic? We might have something with lightning.pw that we can call cloud hosting. It is build for ProcessWire and we're working on new features that focus on making development easier. Unfortunately we have to fight against big problems with our FTP service and we did some minor backend improvements. Next up is the Snapshot and own Profile function, then a Dropbox integration and everything beyond is just a point on the roadmap at the moment. I just want to remark that lightning.pw is only intended for development. We don't want to handle the hosting of a real live site because. That's why we have those random names and the long domain. A migration tool between a life site and dev would be nice and might be coming in the future. _ Maybe you can find a hoster that doesn't has the "cloud" stuff in their marketing but just offers solid hosting with a snapshot functionality? I could also think, that the backup module from PW 2.5 offers a great way to "save" a site. But that doesn't help with the staging functions. Did you had a look at DigitalOcean?

I'd give the second one 34% then it's at least symmetrical

Yeah I looked at that, it's a nice solution but not quite what I had in mind. Thanks for the suggestion though. Looks like there's a lot of cool stuff to find down there, thanks for the link!

Here is a more personal thing I guess: For me mobile first is more about content then about graphical decisions. There was a trend, (i'm happy that it's mostly gone) is to just hide stuff in the mobile environment if it wont fit the viewport as mobile was a thing people implemented as afterthought. While I think mobile is as important as desktop and should be developed in parallel or strongly kept in mind how to handle. Then there's always my question: When information is not important enough to show it on mobile, what is the importance for this info for the desktop. I do not say it's always a good practise to use the same content everywhere as the environment where the content lives has it's own properties.

Joss: glanced through this quickly, and so far I'm liking it. Your terminology is a bit "unique", but that's partly about semantics -- adaptive is actually not the same thing as responsive, etc. Apart from that, this seems like a very good starting point for someone with limited knowledge. Anyway, it's possible that I just missed it, but you might want to cover some common responsive patterns, especially navigational ones. That's one of the areas where even seasoned web experts tend to struggle. Google has some pretty awesome resources on patterns and a few other things you might want to check out for ideas.

Oh, this sounds interesting! Will have a look as soon as I can.

Not that I necessarily think it is a good idea that you're logging people in using the password in the url! But I thought it would be a good idea to add this functionality anyway - so with the new version you can now control the character sets used in the automatically generated password, as well as its length. Turning off the "Special Characters" set should take care of what you need. Let me know if that works for you.

@pwired: I communicate with clients regularly, and the clients I work with tend to understand common sense. They don't have to be professionals to understand that system X might not be the best choice for them because a) it's not scalable, b) it's not secure, c) it's not powerful or d) it's going to be bloody expensive. The client does have to trust my word as an expert, though.. and if there's no such trust, the project is pretty much doomed anyway

Tom, You can use WireHttp's get() and getHttpCode() methods for this.

"Dumbing down" Teppo's points to something a non-technical customer will understand a little easier : ProcessWire has most common features built-in, custom fields and admin templates are easy to do as well so it can be set up to work around your needs ProcessWire is the ideal platform to grow on - there are no roadblocks that can appear in other systems (it's capable of doing almost anything and doesn't mind you changing direction along the way) ProcessWire is secure. Never had a security flaw unlike some other systems where they patch for security systems every other month ProcessWire is fast - faster with ProCache (the fastest you can technically get!) ProcessWire is scalable, so if you need to support hundreds of customer accounts, or run an online ordering system, you can ProcessWire is Open Source and well-supported. It keeps costs down and there's an excellent community of developers behind it. I crossed out bits that I initially wrote that can be skipped as they are a bit negative, but left them there if you want to use them. As for the "Why can't you do it in Wordpress for me?" I think you answered that in your previous post pwired - if they insist on that then skip the job The thing a lot of people get hung up on is selling the system. At the end of the day, aren't people hiring us because we're skilled at what we do? If they don't value your knowledge and expertise despite explaining the benefits and want to use something else then you have to make a choice - use a system you don't want to use or turn down the work. To be brutally honest, if they won't listen to you at this stage it's worth considering if that might continue throughout the whole job and sap all the fun out of it for you. Having worked in retail a long time ago, I disagree with "the customer is always right". I prefer "the customer may have some valid points", but more-so in web development they should be listening to your suggestions. They then make the decision whether to take that advice or not of course, but you've at least done your best up until that point. --- A day I'll always remember working in retail is the time I was asked by a customer to check if an item of clothing was available in other sizes upstairs, Having just brought out all the sizes we had, I informed him there were no other sizes. He insisted I go and check. I assured him they were all out. He stormed off after telling me that I had lost a sale because I couldn't be bothered checking. You can't help some people

Hello everybody, We've just updated AIOM to Version 3.1.4. This is a minor update including the following changes: Bugfix: CacheFiles for Pages are now deleted when a new minimized file is created Bugfix: An error is thrown if the document root is different to ProcessWire's base path If you find additional bugs or have some feature wishes, please open up a ticket at our GitHub repository. Thank you! Marvin

I remember that this is also with configurable modules, if you have a textarea in a config screen where you should add params one per line, for example, and if you simply end the last line with a "new-line char", line one (new-line-char) line two (new-line-char) line three (new-line-char) hit submit, you will get back your content with three tab characters added! If you do nothing but only hit submit once again, you will get three more tabs added, and so on and so on. Whereas if you let out the last "new-line-char", you will get back only the content you want, without added tabs: line one (new-line-char) line two (new-line-char) line three This is with PW 2.3, 2.4 and 2.5, you can test this simply by make the HelloWorld Module configurable: class Helloworld2 extends WireData implements Module, ConfigurableModule { public static function getModuleInfo() { return array( 'title' => 'Hello World 2', 'version' => 2, 'summary' => 'An example module used for demonstration purposes.', 'href' => 'http://processwire.com', 'singular' => true, 'autoload' => true, 'icon' => 'smile-o' ); } public function init() { } static public function getModuleConfigInputfields(array $data) { $form = new InputfieldWrapper(); $field = wire()->modules->get('InputfieldTextarea'); $field->label = 'Textarea'; $field->attr('name', 'textarea-value'); $field->attr('value', $data['textarea-value']); $field->columnWidth = 100; $form->add($field); return $form; } }

The main "selling points" for ProcessWire I've used in the past are flexibility, cost-effectiveness, security, performance and scalability. The order depends on the client and his/her specific situation, but there's always something you can use: If the client wants something large or very specific but doesn't have an endless amount of cash to spend, ProcessWire is a very good choice, as it has built-in a lot of common features and the rest (ones that probably won't fit any pre-made solution anyway) are usually much easier to build than with certain other systems. If the client isn't entirely sure about his/her needs and/or those needs might change in the future, it's good to explain that with ProcessWire there's always room for growth. I've never, ever said "ProcessWire can't do that" (and probably never will). ProcessWire is secure, period. Zero known vulnerabilities, built-in CSRF protection, various security measures against things like cache poisoning and session hijacking, *almost zero possibility for SQL injections*. With or without the buzzwords this should be of interest to the client regardless of their technical know-how. ProcessWire comes with a whole collection of native caching methods and has pretty awesome level of performance even without any caching at all. If the client is worried about how the system will hold, toss in ProCache (or simply mention that it's easy to setup later if such a need comes up). I've managed sites with tens of thousands of pages and I know that there are a lot bigger sites than that. I'm not sure about EE, but I wouldn't even dream of doing something like that on certain other systems. Not sure if this really applies to your client in this case, but it's good to keep in mind anyway ... and, of course, there's the "it's 100% open source" thing. Many clients seem to value that nowadays.

<?php $graduates = $pages->find("template=graduate-detail, sort=-date"); foreach ($graduates as $graduate) { echo " <img src='{$graduate->graduate_photo->first()->url}' /> <h3>{$graduate->title}</h3> {$graduate->graduate_summary}<br/> <a href='{$graduate->url}'>Read more</a> <hr/> "; } ?>

Hi Nico Currently lots of people are actually switching from TYPO3 to other CMS and IMHO this will be also be the case in future as they simply made to many codebreaking changes to extensions where they kept the name, but after updates your complete site was blank etc. So people get frustrated. Like us too by the way. We were looking long time for another CMS which has most or evenmore benefits than TYPO3 and I ampretty sure we found it in Processwire. it is faster very modularized multidomain capable (i.e. we made a site for 400 churches in one TYPO3 - and they now need to update from TYPO3 4.5 to 6.2.6 and are also not happy that many things no more work like before) multilingual and has multilingual SEO (if you adjust your module which you just released - it's great thanks) you can have profiles and very easy backups of your sites and profiles using the profile exporter (a think that was missing in TYPO3 all those years!) the core is separate and it can be updated much easier than in TYPO3 In TYPO3 6.2 you can now create profiles and import them >>> IMHO one way to build a migrator to processwire! and to move customers over, another way is the .t3d export of complete branches or only single pages. It is an internal format for TYPO3 where you can afterwards all data back into another TYPO3 page. Also this could be a great way to use for an importer from TYPO3 to Processwire as it imports all kind of data and files and relations. -- Like said we have lots of customers and usually they ask us to build a TYPO3 website (since 2002 we are doing that) but meanwhile we suggest that they switch toprocesswire. The main problem for all those companies and people is that they ran their sites often in TYPO3 for many many years and are now afraid that it will be very difficult to import their current site data from TYPO3 to processwire. If there would be an importer like your wordpress importer than it would be quite easy to switch customers to processwire. Another 2 problems - (need to discuss that in another thread) is the flexible templating for editors what is available in TYPO3 and now wordpress and drupal but still not in Processwire. and the Digital Asset management which id great in TYPO3 as you can integrate dropbox, googledrive using a File Abstraction Layer and the build in fileadmin is great to with his Meta Data management (similar to DAM). Those things are still missing Processwire but I hope that the Gallery Extension will be released soon as it looks great. Let's see. The biggest hurdle to convert customers from TYPO3 to Processwire is actually their data. When I did the coding of the UNESCO Bangkok website 2007-2010 they had about 550 pages with 16.000 Content Elements and 25.000 Digital Assets (in DAM Digital Asset Manager). East West Center (2008-2010) was very similar to that, but had additionally lots of user data coming from their editors and every day lots of news articles and their categories and tags and their specific permissions. This site was also TYPO3 and is now Drupal (also done with an importer to Drupal by Srijan Technology a former TYPO3 and now Drupal supporter) - http://www.srijan.net/work/typo3-drupal-east-west-center/ Those are sites we name here only as an example as we had worked before with it, but to be able to convert those sites incl their user rights management to processwire would open up very new perspectives to Processwire. This is Enterprise Level! Beside this of course there are tons Universities, NGOs, Schools, Governmental, SME and lots of small TYPO3 websites which meanwhile often complain that TYPO3 in Version 6.2 is to slow, getting to instable and that with each new update you don't know if your site perhaps will turn blank/will be inaccessible. In other words NOW is the right time to crack that nut and convert more and more of the still existing customers to Processwire. A module which would do that would be just ideal for that purpose. Perhaps you can "reconstruct it" ;-) even it's already 2 years ago you did give it a try. Perhaps those two links canhelp you to get such a module done: https://www.drupal.org/project/migrate https://www.drupal.org/project/typo3_migrate https://www.drupal.org/node/1188446 Similar to the processwire approach they are using a general Module and a CMS specific (in this case TYPO3) module the latest update is 2013-Oct-19

Sorry netcarver, this will be a late answer. The reason we offer mueslis, and not other things is because our product is really the best we can offer without spending too much of the money that will come if the campaign goes well. We thought of alternatives, but they would either be too expensive, or take too much of our work and energy in a time when we will be completely focused in opening the café. Offering our own product is always the best balance between more value and less spendings in any business, right? Of course we thought about people that won't be in Porto. We thought of sending our very nice postcards for instance, but only sending them to everyone (if we get all the money we need, we are necessarily talking about lots of people) would make it too expensive for the real value of it. That's why we have the symbolic offer of writing all the names somewhere in the café, and saying that there is no limit to using the muesli vouchers, like this people can use it at any time that they come to Porto. Of course we can make an exception for PW users, and I love André's idea. There will be for sure a hand drawn surprise for all of you that contribute, even if with 1 euro edit: And we sure need everyone's help at this point!! Thanks for the heads up André! By the way, great news, we were featured on the website of one of the main Portuguese newspapers http://p3.publico.pt/vicios/gula/14236/casal-de-designers-quer-abrir-um-muesli-cafe-no-porto

Apologies, Joss, I'm sure the posts were meant as questions not complaints.

Gamified CMS. Cool

@MindFull: Thanks for the updated info, it was enlightening. Is the VPN down more often than their Internet-connection? The reasons behind these questions is that if you need 10+ masters, I would suggest a technique Flickr, for an example, uses. You can actually check their post about it here: http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/ - it's a really simple method If only the VPN-downtime is a problem, you could consider running the ticket-servers on the Internet. If things cannot be reliant on the Internet-connection either, then in my opinion, the simplest solution would be using the same method described in the article above, but just using it locally. Either way, such implementation would require hooking to the saving of new pages and just prefixing all IDs with a prefix assigned for each of the PW-instances (read from the site's wire('config') for an example). A three digit prefix would probably be enough to cover all of the customer's expansion needs (forever). Just an example Corporate instance 1: 100 + <local ticket ID> Corporate instance 2: 101 + <local ticket ID> Branch instance 1: 200 + <local ticket ID> Branch instance 2: 201 + <local ticket ID> ...and so on. This would work without any hacks to PW, because you are allowed to set the ID for new pages. UML, urgh, I feel you there!

Very nice. I would have considered this for my last project a few weeks ago. I found theming is too limited for the embedded calendar, so I ended up using a fullcalendar fork on Github that added a Google-style agenda view. Still not ideal, but a rather nice interactive calendar without iframes. It would be worth taking a look at if you're wanting to add more flexibility.

Hehe, if you can get the address of Ryan's public calendar for releases, I'll add it as a default feed.

Does it come complete with ProcessWire release deadlines?

Well, gentlemen, I think Soma is always looking for volunteers to help....

Hello everybody, I would like to show you one of my last projects: http://www.effectiveminds.de Would be great if you could give me some feedback ! Here some technical details: Main modules used:FieldtypeCropImage FieldtypeMapMarker ProcessRedirects Front-End-Scripts:Stellar.js jQuery Easing Magnific Popup jQuery Waypoints

I found the answer to my question in another topic. Linking it here for seekers to come )

Take a look at Soma's gist. It loops through all the fields of your page and displays a form. Then on Submit of the form it again loops through each field and saves the value. It also includes all styles and scripts that you need for your form to work on the frontend. This is working great for my frontend form. If you need help implementing it, let us know.

I'm implementing a custom field type based on Ryan's Event field type that uses a custom table for storage. I have compared performance to other methods like using a pages field. And the custom table field is much much faster, both when saving and querying values. So I'd recommend going with the custom table field following Ryan's Event field type module.

Maybe it can steal an idea from Ryans table field - have its own table. Or, it could also have its own PW page structure, effectively a "related" page to the current page, that is stored under admin somewhere in the same way repeaters are. Though I think a single table might be more efficient, query wise. However, just to change my mind again, the other day I put on my own site drop downs for Open Graph page type (article and so on) and the same for twitter. I did those with a page field so I have started with the most common five or six, but can add more on the fly as normal with a page-field. Useful functionality for this kind of thing. So, maybe a mix!

@teppo: To be honest: I didn't think about that... Maybe I'm switching to create real fields so multilanguage will be easier, too. Have to think about it later today

Was going to mention this earlier but it slipped my mind, so: Nico, what's your take on the storage method this module uses (saving all content to module config, i.e. the data column of related Modules table entry) and the obvious limitations it causes? Based on some quick testing, using suggested description length, this module should be able to store data for roughly 300 pages -- though actual number depends a lot on the stored data itself. I was just wondering if it would make sense to reconsider the storage method, offer an alternative method for large sites, mention this somewhere.. and/or perhaps make the module aware of how much "quota" it still has? I'm asking 'cause this seemed like an interesting choice for some of our sites, but it's not that rare for those to have hundreds or even thousands of pages.. so if the client ever gets too enthusiastic, there's going to be a problem Also: you might want to add garbage collection for removed pages. That's going to limit the scope of aforementioned scalability issue a bit.

New update: 0.3.0 Added options: - exclude Templates - Google Analytics - smart values - use parents values if empty

Just working on some more options (like using parent values, smart values, excluding templates, special permissions, ...). After that I will update all of the descriptions