Robin S

I think this should work... <a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion-1" href="#accordion-1-<?php echo $presalefaq->id; ?>"><?php echo $presalefaq->title;?></a> ... <div id="accordion-1-<?php echo $presalefaq->id; ?>" class="panel-collapse collapse"> ...but your solution is fine also.

@godmok, what is the maximum number of words you can put into this search query before you hit the MySQL limit? I would have thought that would be a lot of words; more than any person would type into a search input. I have a site that explodes and loops over all search terms using the %= LIKE operator, searching within 12 fields. I can throw whole paragraphs of text into the search input without coming up against any MySQL limit.

@Macrura, I also haven't looked in detail at Qualtext's module, and there are some similarities to both Selectize and Media Manager. But at a glance I can see some differences from Selectize: Image upload > page creation is included in the module. Uploaded images are pixel-compared for uniqueness to avoid duplicates. The ajax-loading features that come with extending InputfieldPageAutocomplete would be useful if you have thousands of image pages. Ajax-loading is possible with the jQuery Selectize plugin but not offered out-of-the-box in your PW module (please correct me if I'm wrong there). So a very worthy contribution to the PW module ecosystem I think.

Hi @Qualtext, Nice job on the modules! Most of us around here are not true pros, and I don't think you need a pro to finish off your modules - you're doing great so far and you're nearly done. Just stick at it. You've probably seen it already, but this is the docs page that is particularly useful for module development: https://processwire.com/api/ref/module/ The bits I quote below are from this page. It isn't necessary to merge everything into a single module file. It's not unusual for a single module release to actually contain two or more modules. Put both modules inside the same directory, decide which is the primary module and have that module install the other automatically by using the "installs" property in the getModuleInfo() array. This takes care of item 1 or 2 in your list of installation steps. Another thing you could do to finish off your modules for release is add code that creates some of the required pages and templates. You can use the ___install() method to do this. In your list of installation steps I think your install method could potentially take care of the following items: 3,4,5,6,7,9. Items 8 and 10 you leave up the user. Search the forum and API docs and look at the code of other modules to understand how to create templates, fields and pages via the API. Give your auto-created templates/fields/pages names that are unlikely to be already in use, e.g. prefix them with the name of your module class. The labels/titles can be anything though. Here are some links to start with:

I can't reproduce this. I can edit a textarea on the frontend and no HTML markup creeps in anywhere. Markdown works as expected when the Markdown textformatter is applied to the field. Do you have any other textformatters applied to your textarea? Any browser extensions that might be interfering?

You could group some config fields inside a fieldset and set it to collapsed. $fieldset = $this->modules->get("InputfieldFieldset"); $fieldset->collapsed = Inputfield::collapsedYes; // add some fields to $fieldset

If you enter PHP code into an inputfield in Page Edit you would have to eval() it in your template in order for it to execute. But the idea of entering PHP code into Page Edit is really not good. If you want to execute a PHP block within some HTML coming from Page Edit then use the Hanna Code module.

Ahh, good idea!

Hi Adrian, My Custom Inputfield Dependencies module is released and the forum thread is here. Not a very precise module name - I struggled with it. You'll see that the effect of my module is similar to what you propose above, but using what is available in the core (and Hanna Code) now. But I think it would be cool to have new features added to the core to allow this directly in field settings like you propose, so if you want to make a Github request I'll gladly add my +1. Hopefully you can use Custom Inputfield Dependencies for what you had in mind in this thread's original post.

Custom Inputfield Dependencies A module for ProcessWire CMS/CMF. Extends inputfield dependencies so that inputfield visibility or required status may be determined at runtime by selector or custom PHP code. Overview Custom Inputfield Dependencies adds several new settings options to the "Input" tab of "Edit Field". These are described below. Note that the visibility or required status of fields determined by the module is calculated once at the time Page Edit loads. If your dependency settings refer to fields in the page being edited then changes will not be recalculated until the page is saved and Page Edit reloaded. Usage Install the Custom Inputfield Dependencies module. Optional: for nice code highlighting of custom PHP install InputfieldAceExtended v1.2.0 or newer (currently available on the 'dev' branch of the GitHub repo). The custom inputfield dependencies are set on the "Input" tab of "Edit Field". Visibility Show only if page is matched by custom find Use InputfieldSelector to create a $pages->find() query. If the edited page is matched by the selector then the field is shown. Show only if page is matched by selector As above, but the selector string may be entered manually. Show only if custom PHP returns true Enter custom PHP/API code – if the statement returns boolean true then the field is shown. $page and $pages are available as local variables – other API variables may be accessed with $this, e.g. $this->config In most cases $page refers to the page being edited, but note that if the field is inside a repeater then $page will be the repeater page. As there could conceivably be cases where you want to use the repeater page in your custom PHP the module does not forcibly set $page to be the edited page. Instead, a helper function getEditedPage($page) is available if you want to get the edited page regardless of if the field in inside a repeater or not. $edited_page = $this->getEditedPage($page); Required The settings inputfields are the same as for Visibility above, but are used to determine if the field has 'required' status on the page being edited. https://github.com/Toutouwai/CustomInputfieldDependencies http://modules.processwire.com/modules/custom-inputfield-dependencies/

The problem with redirecting back to the Lister is that you will lose your current page in the pagination and any filters that were applied, which IMO would be pretty annoying. The nice thing about the modal editing is that everything is just as you left it after you save.

Lister Pro has an option to edit links in a modal window. If you don't have Lister Pro I think it would be possible to turn the edit links of the core lister into modal links with a hook or JS. Edit: for non-Pro lister you can make edit links modal using Admin Custom Files. Enable for process "ProcessPageLister" and add file "ProcessPageLister.js"... $(document).ajaxComplete(function(){ var $a = $('.PageListerActions .PageEdit').not('.PageAdd'); $a.addClass('pw-modal pw-modal-large'); $a.attr('data-buttons', '#ProcessPageEdit > .Inputfields > .InputfieldSubmit .ui-button'); });

Check out Profields Table, Repeater or Profields Repeater Matrix, PageTable (can't find a good link for this but it's an installable core module).

Hi Adrian, I have a module that could be helpful here - just putting the finishing touches on it and will release this weekend. Cheers, Robin.

A repeater will work, but it's sort of overkill for repeating just a single line of text. Behind the scenes it is creating a page for every line. This is probably the way to go. If you wanted your own custom markup you could explode and foreach a textarea. $lines = explode("\n", $page->my_textarea); if(count($lines)) { echo "<ul class='my-special-list'>"; foreach($lines as $line) { echo "<li class='my-list-item'>$line</li>"; } echo "</ul>"; } For sure, and for more complex repeatable items see the Table fieldtype.

I assume that when you say parent and child you are talking about pages. If you need to edit the fields of the child pages directly in the listing then you could use Lister Pro for viewing the children list and editing the fields using the inline AJAX editing feature: https://processwire.com/blog/posts/inline-ajax-page-editing-comes-to-listerpro-processwire-2.6.6/ If you just need to show the fields from the child pages then you could generate a table from the child pages using Matrix or RuntimeMarkup.

Not to put you off making your module, but I believe RuntimeMarkup can do this.

I did a bit of a test. I'm using delayed output with an auto-appended "_main.php". I created a different append file "_main_index.php" for the purposes of rendering the index field: just echos the region variables without any HTML elements. Then in /site/ready.php... $this->pages->addHookAfter('saveReady', function($event) { $page = $event->arguments('page'); if($page->template->name !== 'basic_page') return; $page->index = $this->sanitizer->textarea($page->render(null, ['appendFile' => '_includes/_main_index.php'])); }); All works well, no errors or multiple calls to the hook when saving from the admin or the API. Maybe it's the fact that I'm hooking after saveReady that make the difference. Edit: hooking before or after saveReady should make no difference. From the hook docs...

Just realised that 'modal=1' is hiding the header/footer with CSS rather than different markup being rendered. So easy enough for me to add some CSS to hide the notices too. #notices { display:none; }

I'm working on a module that needs to load a page inside an iframe (inside a CKEditor dialog). Currently I am loading a plain HTML file and doing all the processing with Javascript, which works fine. But I'm wondering what options are available to me if I wanted to load a PHP/API-powered page in the iframe. PHP files cannot be directly loaded inside /site/, so I thought about the following options to work around this. I'm keen to get any advice about which would be best and any other solutions. 1. Have my module copy a PHP file to the root directory, where PHP files may by loaded. This file could then bootstrap PW. This option seems messy - I don't think it's good for a module to copy files to the root. 2. Make a Process module that creates a hidden page under Admin. The problem I'm finding with this is that it's difficult to avoid visible admin template elements being rendered in the page. This is similar to what @blynx was asking about here. I can append 'modal=1' to the URL to avoid the admin header and footer (I think that is what @horst's modules do) but I'm finding that message notifications (e.g. compiler notifications) can still appear and I don't want them in my iframe. Is there another URL parameter (or a hook maybe) that I can use to prevent notifications? 3. In the install() method of my module, create a new template and a new page and assign the template to the page. I wouldn't want my template file in the /site/templates/ directory but I figure there is a way to assign a template file that is inside my module directory. This option seems like it will work, but it involves more code for the page/template creation and deletion on uninstall than the elegance of the automatic page options for a Process module. 4. Some kind of hook to page render that prevents the normal admin template markup and outputs my custom markup instead. I guess with this option I wouldn't even need a page - just look for some GET variable in the URL. Would this be a good solution? Any other suggestions for how I can load a clean page with access to PHP and the PW API? P.S. It isn't a negative for the loaded page to be using the admin template if I can find a solution to the notifications issue as part of the objective is to use the jQuery version and inputfield styles that come with the admin theme.

Just curious: do you need this index field to achieve some functionality or are you using it to optimise search performance? Just wondering why you wouldn't include all the fields you want to search in your selector instead of merging fields into the index field. In terms of dealing with the URL segments, I suppose if you have a detail view that uses a /detail/ URL segment and you think that is the view the visitors will want then you could append /detail/ to the link hrefs in search results for pages with that template.

Could it be that the host is running some maintenance task on a regular basis that makes the file system unwriteable? Of course that shouldn't happen, but at this point if you're willing to try anything you could copy the site to a different host and see if the issue still occurs. I guess you would need to simulate browser traffic for testing - I don't know much about that, maybe JMeter?

I'm not sure what could be causing the 500 error. The Apache/PHP/PW error logs might shed some light. If this is happening on a live site then it could even be caused by mod_security - turn that off if you can or check with your host. Rather than using your parseContent function you could consider rendering the page with a different template that is created with the index field in mind. $page->render($filename); // $filename assumed in /site/templates/ See this post: Or you could loop over the page's fields in the hook, checking for the type of each field and preparing it's value for the index field accordingly. foreach($page->fields as $field) { /* you can get the value... $page->get($field->name); ...but you'll want to treat it differently based on field type if($field->type == 'FieldtypePage') { ...etc... } */ }

I'm pretty sure Page fields are only stored as IDs in a cache field, and I expect Repeaters and PageTables would be the same. Which greatly decreases the usefulness of cache fields. Ryan has said this:

You might find the Page Rename Options module useful - you can set it to keep page names in sync with page titles when they change.