Robin S

Datetime fields are stored in the DB as timestamps - this is true regardless of whether you have a timepicker on the inputfield or not. So you can output the value of a datetime field in any format you like. Get the timestamp with getUnformatted() and then format it with date(). You could check the time to see if it's 12:00am and if so format the timestamp without a time component. But I don't think you can use code to distinguish between situations where no time was entered and 12:00am was deliberately entered.

Ooh, ooh, me first! You should grab a template, give it a document, tag and description fields There's no document library module (that I'm aware of), probably because a module isn't needed for something like this. For your task the basic item you are dealing with is a document record. This is a collection of information: URI, description, tags. In ProcessWire the 'page' is the unit that is typically used to store a collection of information. And in ProcessWire, a page isn't necessarily a complete page that visitors view on the website front-end; a page can consist of only a title field, and you will probably use something like this for your tags/categories. The broadened definition of 'page' in PW is one of the things that can be confusing at first for new users. It took me a bit of time to adjust my idea of what a page can be. So as you predicted, you would create a template to use for document records and give it the fields you need. Then you add one page per document under a chosen parent in the page tree. It's up to you whether you make individual document records viewable as individual pages on the website front-end. You might decide you don't need that and only pull in information from the records to display as part of another page (search results or category listings). A great place to start is Ryan's Skyscrapers profile: http://demo.processwire.com/ http://modules.processwire.com/modules/skyscrapers-profile/ Replace the concept of 'skyscraper' with 'document' and you'll see how PW can be used as a document library. I did exactly that for the first website I built with PW: http://ref.dunestrust.org.nz/

Besides using the Fieldtype module @LostKobrakai suggested (I haven't used it myself), you could create a simple Process module to list pages with the product template alongside the calculated VAT inclusive price. Check out the example module code shared by @renobird here. Edit: I just installed RuntimeMarkup and it works great for math calculations. So using this module would be the way to go if you want to see calculated values in a Lister.

I'm no expert in this, but the way I see it is you have a base price and then one or more 'modifiers' that act on the base price. A modifier could be a tax rate, an export tariff, an addon handling fee for a large item, or something else. You don't work out the results of these modifiers for each base price ahead of time, you just apply them using PHP math operations as needed depending on what options the website visitor has selected. I think the performance impact of basic math operations like this would be negligible.

Me too. I switch Tracy on only when I need it. Having a shortcut to toggle Tracy on/off would be great.

Another solution... Instead of wrapping the link around the textarea on the index template, place the link as a sibling to the textarea and then use CSS absolute positioning to place it over the textarea. index-template <div class="my-text"> <a class="my-link" href=""></a> <?php echo $page->textarea; ?> </div> CSS .my-text { position:relative; } .my-link { position:absolute; width:100%; height:100%; top:0; left:0; z-index:2; }

Rather than having two price fields... price price_including_vat ...have you considered having one price field and one VAT rate (%) field? price vat_rate And then you calculate the VAT inclusive price on-the-fly. Seems like it would be easier to maintain this way.

Hi sudodo, Welcome to the ProcessWire forums. Sorry to hear you're having trouble. The admin login page at http://rightangle.space/processwire/ is loading normally for me. If you are seeing an error message when attempting to access this page could you post back with the contents of the message? Do you still get the error if you try a different browser? And if you access the page in your browser's private/incognito mode?

Hi Barido, Welcome to the ProcessWire forums. I think there will be a number of solutions you can choose from. A few that occur to me are below. 1. Without using any modules and just working with the default Pages tree, you could use either the Published/Unpublished state or the Hidden/Unhidden state of the job page to switch a job from Active to Inactive (or vice versa). These states can be set directly from the Pages tree without needing to open the page for editing, as shown in the screenshot below. If inactive jobs need to be shown on the website front-end then the Hidden/Unhidden state would be the one to go with. In your templates you can test for the hidden state using the $page->isHidden() method. 2. You could use the Batch Child Editor module to toggle the Published/Unpublished or Hidden/Unhidden state. 3. You could purchase the Lister Pro module. This module has a number of cool features, one of which is the inline editing of page fields directly in the page list. So if you wanted to use a checkbox field in the job page to store the active/inactive state you could toggle this field via Lister Pro.

Just a guess: there might be a setting in sql_mode that PW doesn't like. Maybe NO_ZERO_DATE or NO_ZERO_IN_DATE - I'm not sure what the PW requirements are regarding sql_mode settings.

Is this a container page that holds multiple blog posts? If so $page is likely to be the container page, not the blog post page. In your loop that iterates the blog posts you would replace $page with whatever variable you have assigned to a single iteration. Something like: $posts = $pages->find("template=blog_post"); foreach($posts as $post) { // output post content here... if($user->hasPermission('page-edit', $post)) { // output edit link here... } }

Are you looking to create a Fieldtype module to get a job done, or more as a learning exercise? If it's the former and you place a value on your own time you will probably come out ahead by purchasing the ProFields package. I don't follow exactly what you are wanting to do but I think Table could be suitable, or possibly Multiplier or Textareas. If it's more of a learning exercise then you can expect this to be somewhat challenging, but you have the Events modules as a starting point. Why do you say that the code for the Events modules does not help you? The code is well commented and it sounds like you want to do something quite similar to what the Events modules do.

It's not unusual to hear of a website moving from WP to PW but this is the first time I've heard of one going the other way. Call me crazy, but I thought a business that wants us to believe they are qualified to pass judgement on the software used to develop websites might be capable of doing their own website development and customisation in-house.

And you'll probably want to add something to make sure you only match pages containing my_repeater: $pages->find("my_repeater.count>0, !my_repeater.my_checkbox<1");

You're not the first person to say this so there must be something to it, but that is not my experience. As a PW learner I haven't found working with modules to be a lot more difficult than working with any other aspect of PW / PHP and the docs seem pretty good to me. My experience has been that module development is challenging, but in a good way - you just get stuck in, debug issues as they arise, and ask for help in the forums when you get stuck. This makes me wonder if you are holding back from actually starting on your module while you do 'research' - I'm not sure this is the best way to learn module development and my suggestion is just make a start and learn as you go. Like many things in PW, I think you'll find it's a lot simpler and easier than you anticipate when you're on the outside looking in. Part of the problem with providing detailed documentation for something like module development is that the subject is so broad - a module can be created for any purpose and whoever is writing the docs can't know what you might want to do in your module. By analogy, it's like if you are learning to cook: you won't find much if you are searching for documentation on how to cook in general because the topic is too broad. Instead you have to decide what you want to cook and then look for help with that - how to make a chocolate cake or how to pluck a goose. Maybe you can say a bit about what you want your module to do?

It should be fine to use repeaters for what you want to do. Do you mean Javascript errors or PHP errors? If it's a JS problem then have a look for documentation or examples for using multiple galleries with whatever gallery script you have chosen. For example: http://www.menucool.com/1075/Add-multiple-sliders-to-one-page

Echoing a comment from Matjazp on the blog: it would be great to hear how these traversal problems were solved. Maybe we could have a blog post some time that takes an advanced programming challenge like this, or the findMany() method introduced in 3.0.19, and walks through the process of how it was approached. The initial problem/challenge, the hypothesis of how it could be solved, any missteps or changes in direction that happened along the way, and the resolution. It would be super-interesting to learn how you tackle these things!

Does clearing the cache for ProCache help? The reason I suspect ProCache is that... http://ukmoths.org.uk/thumbnails/crambidae ...exhibits the weird links but when a get variable is appended that would bypass ProCache the links are normal. http://ukmoths.org.uk/thumbnails/crambidae?foo=bar

You have the whole API available to you for module development. The examples above are not specific to modules, but are methods of the Wire class. https://processwire.com/api/ref/wire/message/ https://processwire.com/api/ref/wire/error/ My go-to pages for module-specific info are: https://processwire.com/api/ref/module/ https://processwire.com/blog/posts/new-module-configuration-options/

Sounds like a job for the API Delete fields by name: <?php $field_names = ['field1', 'field2', 'etc']; foreach($field_names as $field_name) { $field = $fields->get($field_name); $fields->delete($field); echo "Deleted field '{$field->name}'<br>"; } Or maybe delete all unused fields: <?php foreach($fields as $field) { if( count($field->getFieldgroups()) === 0 ) { $fields->delete($field); echo "Deleted field '{$field->name}'<br>"; } } Or you could make a form displaying checkboxes for each unused field and select which to delete, similar to what @diogo does here for templates.

Glad you got it working. The sub-selector docs are here but I'm sure you found them by now.

Thanks for the info. Seems that this affects all new map applications and existing applications (like mine) are grandfathered.

If you mean the message in your browser console I think it's just a warning rather than an error. I'm using the Map Marker module without an API key and it's working fine.

Maybe $pages->getById() is the way to go. $my_pages = $pages->getById([1086,1021,1053,1018]);

Here is another way you can get your repeater items, by first finding the pages those repeaters are on. Not tested. <?php // sanitized input $types = $sanitizer->selectorValue($input->get->type); $patterns = $sanitizer->selectorValue($input->get->pattern); $designers = $sanitizer->selectorValue($input->get->designer); $colours = $sanitizer->selectorValue($input->get->colour); // selector $selector = "template=template_with_repeater_field, collections_detail_images.count>0, sort=title"; if ($types != "all") $selector .= ", collections_detail_type=$types"; if ($patterns != "all") $selector .= ", collections_detail_pattern=$patterns"; if ($designers != "all") $selector .= ", collections_detail_designer=$designers"; // here we make sure we only find pages that have the right colour in one of their repeater items if ($colours != "all") $selector .= ", collections_detail_images=[collections_detail_image_colour.collections_colours_group=$colours]"; $results = $pages->find($selector); include './collections-filters.inc'; // not sure what this does ?> <?php if(count($results)): ?> <div class="container-fluid"> <div class="row"> <div class="fabric-list-container collections-results all"> <?php foreach($results as $result) { $fabrics = $result->collections_detail_images; $fabrics->sort("collections_detail_image_colour"); if($colours != "all") { $fabrics->filter("collections_detail_image_colour.collections_colours_group=$colours"); } foreach($fabrics as $fabric) { include './fabrics-list.inc'; } } ?> </div> </div> </div> <?php endif; ?> Another thought: seeing as you want to do all this stuff with your repeater items outside the context of them being fields in another page maybe repeaters are not the ideal mechanism for your data. Could these repeater items instead be normal pages, related to their 'get-for' pages either via a parent-child relationship or via a Page field in the collections_detail_images pages? You can make the collections_detail_images pages easy to add by including them in the "Add New" menus.