Leaderboard

Another major new feature! I have added an Export to CSV mode which generates a CSV file containing the fields for all child pages. It currently supports most field types, including: Text/Textarea/Integer/Date fields Page fields - exports the "Title" if available, or "Name" if not (eg user template), rather than just the page ID File/Images - exports the filenames Profields Textareas - automatically converts field into multiple columns - one for each subfield Profields Multiplier - separates values with a customizable separator - you can choose a line break if you want which is nice when opening the CSV in Excel. This same customizable separator is available for other multiple fields like Page fields, File/Image etc It does not support Profields Table, PageTable or Repeaters as these would get very messy. Note if you want to provide an export for specific Table fields, don't forget to check out: Table CSV Import/Export Fields to be exported can be predefined or customized by the user. Also includes an API export method: //export as CSV if csv_export=1 is in url if($input->get->csv_export==1){ $modules->get('ProcessChildrenCsvExport'); //load helper module //delimiter, enclosure, file extension, names in first row, multiple field separator, array of field names $page->exportCsv(',', '"', 'csv', true, "\r", array('title','images','textarea_test')); //$page->exportCsv() - this version uses the defaults from the module or page specific settings } // display content of template with link to same page with appended csv_export=1 else{ include("./head.inc"); echo "<a href='./?csv_export=1'>Export Table as CSV</a>"; //link to initiate export include("./foot.inc"); } Like the rest of this module, everything is configurable at various levels, so you can include this functionality as a separate tab, or part of the Children tab. You can predefine all settings so the user only has a simple Export button - whatever works best for you. Please let me know how this new functionality works out for you and if you have any suggestions for improvements.

I hope this is related to what you are talking about....anyway I'll take an initial stab at attempting to answer your question. An existing field can be reused under a different context at the template level. Instead of me trying to explain it, here are some references. https://processwire.com/videos/field-template-context/ https://processwire.com/talk/topic/6656-change-field-description-in-context-via-api/ https://processwire.com/blog/posts/making-efficient-use-of-fields-in-processwire/

They now are offering to install PW from the admin interface of your webspace: https://twitter.com/domainfactory/status/603131328826101760 (Fun fact: Almost all of our PW installations run there as we usually recommend DF as our preferred hosting company)

https://medium.com/artificial-labs/why-we-don-t-use-wordpress-anymore-df1c4462cb48

Yes! That's it Much better than my original thought Thanks for your help! Bram

The page table pages are referenced in the field. So how about using this? Unless I'm not getting it what you're after. $pagetablechildren = $pages->get("template=xyz, pagetablefield=$page")->pagetablefield;

It already exists while editing the template and after adding a field, click on it's name. I think you have to save before, but I'm on mobile and can't try.

This is already available within the RTE, I think the same functionality should be brought through to the Image field (note: I am not asking for a media manager )

Some sites need widgets, as they have been called in some systems; a widget can be almost anything, like: tag cloud mini calendar menu quote rotator free text social sharing search contact info map This is a simple way to create widgets that can be shown in multiple "areas" of a page, as well as on specific pages. In this particular method you would need to setup each widget type you want and then determine how best to accept any necessary user input like content, pages select (like for a menu) or settings. This example uses include files for each widget type, and the name of the include file would match the name of the widget type, which is also a page field. In this example, I'm also using ListerPro to provide a widget management page. Fields The main fields used on this widget example are : title widget_location (page select - options in this case are footer and sidebar) widget_type (page select, you would configure your widget types as selectable options) pages_select (would be used for multiple pages and might apply to a menu widget) body - used for plain widgets selector (selector inputfield, used for telling the system where to show the widget) text_structured - for this i'm using a YAML field, but it could just as easily be a table; would depend on what you want to store; YAML would allow this single field to be used for varying requirements based on the widget type, but would be harder to validate and prone to user error; icon - a page select for an optional icon which is being used in the template, and would be shown as part of the widget. Files for each widget type you want to allow users to select from, you would need to create an include file with the markup for that widget, and then add that widget to the list of available widgets. here is an example for a site with several widget types: Selector & Output wherever you want to include the widgets (footer, sidebar etc.) you would run a $pages->find and then foreach through the widgets (in this case finding all footer widgets). In this case the (incredibly amazing new) selector field would be specifying what pages to show the widget on. We assume that most widgets won't have a selector specified, and will default to show the widget. if a selector is specified, we can check to see if this page fits the selector by using the $page->is($selector) syntax. <?php $widgets = $pages->find("template=widget, widget_location=footer, sort=sort"); foreach($widgets as $widget) { // check if the selector field is in use and if so, see if this page is supposed to display it: if( $widget->selector) { if( !$page->is("$widget->selector") ) continue; } $widgetType = $widget->widget_type->name; $include = file_exists("./inc/widget-{$widgetType}-foot.inc") ? "./inc/widget-{$widgetType}-foot.inc" : './inc/widget-footer.inc'; include($include); } ?> this example also has a fallback file in case the widget type is not specified, sort of a default. the widget's .inc file will be unique to your design and how you have it setup.

At X-com we build and maintain ticketingsoftware, named Itix. About 20 Dutch Theatres run our software and since we've dropped maintentance our own CMS, we're slightly migrating more and more of those theatres towards a ProcessWire powered website. Using various API's and synchronisation tools, all needed information and actions are provided to the ProcessWire frontend, resulting in a cool e-commerce solution which is flexible towards the client and scalable for us. Our latest and greates is Schouwburg Venray. Go check it out at http://www.schouwburgvenray.nl The design was done by http://www.dejongensvanboven.nl The technical implementation by us at http://www.x-com.nl

$german = $languages->get("german"); $germanDesc = $page->myimage->first()->description($german); // returns a json string of all languages $json = $page->myimage->first()->description(true);

Just use insertAfter / insertBefore if you need buttons to not be appended after the hidden input: https://processwire.com/talk/topic/9832-how-to-create-an-action-in-an-admin-page/?p=94500

I cannot tell from experience, but I don't think you can make it perfect the first time. I'd do two things: Make a list of "technical words" (hooks, urlSegments, templates, …) and try to translate them. And on the other hand just start translating with the help of this list, maybe append things to it on the go.

I decided on Page::render because this site has a lot of internal urls stored in fields and output via templates that also need to carry the segment. There's also a large, sitemap-style menu that uses the $cache feature, and I didn't want to cache every variation. This way I can cache the large menu aggressively, and use replacements when rendering.

Short version Can we make the Page fieldtype as the tagging engine for images? Long version / real example I started using image tags for the first time after reading making efficient use of fields in PW. There's a part titled Use multi-file fields to replace several single-file fields where Ryan mentions tagging. As I was building a site for an interior designer, I needed an almost identical setup and to tag images with a gallery with "basement", "living room", "garden" and "kitchen" tags. At one stage, my client wanted "basement" changed to "basement and garden" and I had to manually edit about 15 images. No big deal really but it doesn't seem very scalable. Having used the Page fieldtype for tagging blog posts and news and experienced how easy it is to make global tag names changes etc, I wondered if the Page fieldtype could be put on the roadmap as the tagging engine for images or at least as an option.

Hey Mr-fan That occurred to me (pages as single images) and would have a few benefits in this project. I might even go down that route as the portfolio grows. Was thinking too that I could use Lister pro then as a kind of Images manager. Kind like what Soma is doing with his setup. Otherwise, I was just putting it out there that it's be a nice idea? Probably not easy or quick to refactor in terms of the core but would be a nice addition.

In the light of this, I'm joining the beer queue: this feature already exists!

I was put on to Mandrill by Pete (thank you Pete). In my experience if your website sends emails to people, for example you have a booking app and people get confirmations, then the confirmation emails may, sometimes, get rejected as spam, regardless of the fact that they're not. TL;DR Whenever in the PW admin there is a field to do with delivery of email from PW, there ought to be a note / link to an article about the benefits of sending email via Mandrill (or similar service) rather than direct. Boring rant version I had tried to solve this lack of 100% reliable email delivery with DKIM and SPF records (good things in their own right) tuning the content of the email so perhaps it would be less likely to apparently trigger some spam pattern recognition code (for example having few(er) HTML links banging my head shouting Nothing worked. I would appear to have a period of reliability where all emails were getting through, relax... Then BAM! Another spam rejection. The only variance? The receiving email systems. As visitors to the site were many and varied so were their email systems and some of those email systems spam detection algorithms were simply too sensitive for their own good. So it was not my fault but nevertheless my client whose website used the booking system kept gettings infrequent but repeated 'lost' email confirmations. So I made one other change, I sent email via SMTP to Mandrill rather than directly to the client. Mandrill then sent it to the client. This resulted in an unprecedented (and continuing) period of 100% success—zero false positive spam rejections. The reason is simple: my client's domain (or your client's domain) has a reputation as a source of email. It is probably average or good. Whereas Mandrill, who send (Mandrill is part of MailChimp and these are the overall numbers) with this many emails have to have an exceptional reputation, and they do. Nothing I can do on a domain or in DNS can compete with this firehose of good reputation provided by Mandrill. Recommendation If I were a newbie to emailing from PW to people then I could well go through this learning curve myself. To help others I would like to suggest that perhaps wherever there is a field in PW that is responsible for sending email that one of those helpful 'Notes' be auto populated with a link to an article on on the benefits of sending email via an intermediary such as Mandrill.

I have used Mandrill in a PW project before using the PHP Client. https://mandrillapp.com/api/docs/index.php.html Straight foward and easy to implement. I didn't use the stmp because I was using Mandrill templates and filling the placeholders with user data.

Marty, simply skip using renderScript method and directly add the the stuff you need from there.

@Pierre-Luc, $pageimage->page will get you the page; not sure if this is a subfield though for use in selectors;

Thanks Bernhard, that should be safe change, just committed! I also added simple support for adding new pages. Current syntax is this: <?= $fredi->setText("Add new article")->addPage("article", "title|date|summary", $parent) ?> First parameter is template (required), second is fields (optional, uses only title if empty) and third one is optional parent page (uses current page otherwise). It doesn't do much, but works pretty nicely. It redirects to new page after successful save. Name is created from title.

No "Proudly powered by WordPress" in the bottom? Sorry, couldn't help myself

I love Shaun, ...

After some thought: I'm a little undecided as to how much functionality I would want in this monitor. Currently, Jumplinks serves its purpose, and adding to much to it might not be the greatest idea. That said, I would be prepared to release a separate 404 monitor module that includes this functionality. Firstly, Jumplinks would be able to tie into this module if it exists. Secondly, I'd be able to add certain security features to it without bloating Jumplinks. Preferably, I'd want to implement this module in such a way that it modifies the .htaccess file in the following way: when browsing the log, a user with the relevant permissions would be able to blacklist a certain URI for a fixed/indefinite period of time. They'd also be able to block an IP (based on the findings in the log) for a certain/indefinite amount of time. When these 'blocks' are defined/modified, they'd be added to the .htaccess file, and the module would periodically check (lazy-cron-like, say twice a day) to see if the file is up to date. An example would look like this: #< BEGIN ModuleName <last-check: <time>> Redirect 410 /wp-admin # always Redirect 410 /etc # <time>-<time> Redirect 410 /etc.php <time>-<time> Require all granted Require not ip xxx.xxx.xxx.xxx # <time>-<time> Require not ip xxx.xxx.xxx.xxy # always #> END ModuleName For me, this is a performance thing - i.e. booting up the whole PW system just to block/limit access is unnecessary. With the above in mind, this may land up becoming an .htaccess security-driven module, similar to those made for WP (the bain of my existence); however, it would only include essentials. (It would more than likely not be called '404Monitor'.) As said, the added benefit would be that the module can provide a 'safe' list of 404s from which Jumplinks can derive it's data. Thoughts?

I would do it like this: foreach ($page->tags as $tag) { if($tag->allowed_users->has($user)) { //show news item } } That assumes your page field that is linked to users is called "allowed_users". PS Sorry I forgot about the role issue when setting up the page field selector, but glad you sorted it out!

I understand that, but if you want to write about something, make sure you understood at least the basics.

You left out the part how you actually want to handle the data now. If you want them to get simple pages in processwire, than yeah, you'd build the templates to hold your data and then import the data as pages. For the importing part take a look at some of these: http://modules.processwire.com/categories/import-export/ If you need some more basic things for starting out, here you can find how you'd generate a page from the api: https://processwire.com/talk/topic/352-creating-pages-via-api/

Directly fetching only the cells you really need will always be faster than the api. It's the nature of having an additional abstraction layer between mysql and php.

This solves a particular pain and saves much time, so it's worth money.

Definitely money worth module, given it is implemented right.

I would happily pay a lot of money for a comercial module that solves this problem. I am sure a lot of other freelancers and agencies would too, once the benefits of the process are clearly explained. Maybe you could also combine it with a good backup solution - "painless deployment and backups - save time and headaches when developing and iterating rapidly changing client projects"