Robin S

@ryan, could you please make a full profile of the updated Skyscrapers demo available? So it is easily installable for people to try out, like the previous version. It has come up a couple of times in the forums recently.

The Skyscrapers demo is a good example of a collection profile. http://processwire.com/demo/ https://github.com/ryancramerdesign/skyscrapers2 The demo was updated recently and I don't think a full profile of that is available yet. But the template files in the GitHub repo show how the site works. And the old Skyscrapers profile is available here if you're interested.

$page is an API variable, so it's already defined at the time your _init.php runs. $child is not an API variable - it's a variable that you have defined yourself. So you need to make sure it is defined before you try and do anything with it such as $child->created. I don't see $child being defined in your _init.php. I tried both the renderPager() examples you gave and they execute fine. There must be something else that is causing the 500 error. Check your error logs to see if that sheds any light. Are you developing locally or on a live server? If it's a live hosting you may be getting false positives from mod_security if that is installed, so ask your host to disable mod_security in that case.

@Elías Gómez, can you post the code you are using to loop over your event pages? It's hard to offer much advice without seeing that. Also let us know what you have selected for the "Formatted value" in the settings of your image field. As a general tip, if you spend a little time getting to know the Tracy Debugger module you will find it very valuable for investigating these kinds of issues. https://processwire.com/blog/posts/introducing-tracy-debugger/ http://modules.processwire.com/modules/tracy-debugger/

Nothing useful on the body I think but there is a class on the h1 and also its containing div:

I think maybe you are already onto this idea (saw your posts in another thread), but you could use RuntimeMarkup to create a non-editable table view in Page Edit showing the payments.

Hi NikNak. That's correct - think of the role dropdown as a required field. Come to think of it, I will set the that config inputfield as required in a module update. While it would be possible to restrict PageTables for superusers with this module, I deliberately excluded superusers from the role dropdown. My view is that it is part of the PW philosophy that the superuser role is not subject to any access restrictions and I want the module to be consistent with that. IMHO the only user that should have the superuser role is the site developer - you shouldn't give superuser access to a client. Better to create new role for the client with whatever access is needed.

Try ticking the "Make field value accessible from API even if not viewable" checkbox under "Access toggles".

See the pagination docs for how to change the markup/classes output by MarkupPagerNav: https://processwire.com/api/modules/markup-pager-nav/

You'll want to use $page->rootParent as the starting point of your menu. But for a simple menu like this (and even not-so-simple ones) I recommend trying MarkupSimpleNavigation as it covers all the common menu needs out-of-the-box.

I noticed that the position:relative rule that AOS adds to h1 makes the select dropdowns in the ProDevTools API Explorer unclickable.

Well, you should be a bit wary in that a person with edit access to the page could insert some malicious Javascript. If the person editing the website is the site owner then of course they would have no reason to do such a thing. As a general principle I think you should only make editable the parts of the code that it is essential to keep editable. For example, if your client only needs to change the "data-widget-id" attribute then make a text field just for that part and keep the rest of the snippet static in your template file. As an added benefit it also minimises the chances that they accidentally mess up the snippet code.

Thanks! Hope you feel better soon. I tried a few things but I don't have a good grasp of how the recommended way to set inline mode... session.setMode({path:"ace/mode/php", inline:true}) ...relates to the module's implementation of Ace. The only thing I could find relating to the PHP inline mode is in mode-php.js: ... "ace/mode/php-inline" ... So maybe this is an alternative way to set PHP inline mode? Hard to make sense of it with the source being minified.

Spotted a couple of things here. I think you want the last breadcrumb item outside of the foreach loop - otherwise when there are multiple parents you will get multiple copies of the 'active' item. And folks argue over what is the semantically correct markup for breadcrumbs, but when using an ordered list I think the "You are here" text should be outside the list as it doesn't represent a page in the site hierarchy.

By default ACE requires an opening PHP tag for syntax highlighting to work, even when set to PHP mode. But there is an 'inline' mode that enables highlighting without needing the opening tag: https://github.com/ajaxorg/ace/issues/2542 Is it possible to set this inline mode via the API for Inputfield ACE Extended?

Just an ordinary textarea - make sure the Inputfield Type is set to "Textarea" and not "CKEditor. Don't add any textformatters to the field.

You might be interested in this recent thread about rendering page content to an 'index' field with a save hook. I only tested it briefly but with this approach you are in control of what is saved to the index - so for Page fields for example you can save the title or any other subfield you want.

@MaryMatlow , if the widget always occurs in the same place in your template (i.e. the editor doesn't need to move it around) then you could have a dedicated textarea field in your template for the code snippet.

In some modules I am conditionally loading JS to the module config page like this: if($this->input->get->name == $this->className) { // load script }

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