adrian

Have a read about the PHP modulus operator - that should get you started.

Thanks Charles, Please try the latest version. I don't have currently have a PHP 7 setup to test so there might be additional errors, but that one should be fixed.

Hi @dab, Glad you're finding it useful. I haven't used the module on a shared host with cpanel, so I am not sure whether there is maybe some interaction going on there. I don't think I have ever seen the module itself create these files. Obviously the module responds to: http://pw.dev/?hash=4ba942b72726bbc0fa527c0c3aa69f2bc6817534 but I don't know where that index.html version is coming from. Any chance there is a caching mechanism at play here. Maybe even ProCache? although I doubt it.

Unless I am missing something obvious, it should just be a matter of enabling url segments on your home template, then using the value of the segment to get the page details for that user name. https://processwire.com/docs/tutorials/how-to-use-url-segments/

Glad to hear - if you have a minute, it would be great if you could explain what was wrong so others might learn. Are you saying that despite the homepage being protected, guest visitors are having full access to the homepage? Is this your script that is redirecting to the homepage, or the PP module? Remember that the login form is injected into the currently viewed page - it is not a separate page.

Following on from Kongondo's answer: https://processwire.com/talk/topic/4134-include-template-name-in-admin-page-list/ Although you might want to do it via the ProcessPageList settings so that it works for all templates: /processwire/module/edit?name=ProcessPageList

Ok, so just save the field on the current page: $page->of(false); //sorry, I forgot this in the above examples $page->lp_item = $sanitizer->text($input->post->lp_item); $page->save('lp_item'); You can make it even shorter with: $page->setAndSave('lp_item', $sanitizer->text($input->post->lp_item)); That's it! Don't forget though if you have multiple users editing the same field on the same page you may want to deal with possible conflicts if they are editing at the same time.

You have to choose a page to save data to. The template for the page has to have the lp_item field in it. You could create a new page for each form submission - maybe like this: $p = new Page(); $p->template = "my-form-template" //use the name of the template that has the lp_item and other required fields in it. $p->parent = $page //save as child of the current page, or choose another page here $p->lp_item = $sanitizer->text($input->post->lp_item); // change the sanitizer type as appropriate: https://processwire.com/api/variables/sanitizer/$p->save('lp_item'); $session->redirect('./');

Take a look at this PR (https://github.com/ryancramerdesign/FieldtypeMapMarker/pull/11) - I haven't tested it, but hopefully it will take care of what you need.

What is $u meant to be? Is that the current user? Assuming it is and lp_item is a field on the user template, then try this: $user->lp_item = $sanitizer->text($input->post->lp_item); // change the sanitizer type as appropriate: https://processwire.com/api/variables/sanitizer/ $user->save('lp_item'); $session->redirect('./');

You can ignore my last post - @dg decided to go with the approach of sending all debugger bar requests with: XDEBUG_SESSION_STOP=1 which seems to solve the issue for me. So for those of you who manually switched to the stable branch, I would suggest updating to the latest version of this module and switching back to master. I will be removing the old stable option (or swapping them when the master is released as 2.4 stable). Please let me know if things are running fast again with the new version and master branch - thanks!

Those of you who noticed very slow rendering of the Debugger bar, but noticed significant improvements when you switched to the stable version of the Tracy core - were you all running xdebug? I noticed that it speeds things up significantly (almost as fast as the stable branch) if you disable xdebug. If that is the case for you it might be helpful if you could contribute any ideas to this issue: https://github.com/nette/tracy/issues/157#issuecomment-219547179 and either confirm that disabling xdebug helps, or it doesn't and any other info you have that you think might help to solve it. Thanks! Ignore this - see my next post.

You need to reference the field from the selected page(s). If the page field is set to store multiple pages you usually want to foreach through them: foreach($page->page_field as $pf) { echo $pf->title; } That will return the titles of all the pages selected.

The easiest way to install is to paste: ElasticSearch into Modules > Site > Add New > Module Class Name I don't know much about the Elastic Search module. Another option which I know handles searching PDF files is: http://modules.processwire.com/modules/indexer/

To quote Ryan's latest blog post: https://processwire.com/blog/posts/more-images-upgrades/ - note the bit about "custom meta data fields"

Are $text1 and $text2 fields on the same page as the images field? So they are the same text for each image? It sounds like what you want is $page->text1, but until we know exactly where $text1 and $text2 are coming from, it's hard to know.

I am seeing this too - would you mind posting an issue on Github please? In case others reading this are confused - it's the new icon in the breadcrumb trail that ottogal is referring to.

Any chance you have: $config->moduleCompile = false; in your config.php file?

I have just pushed a fix for this - sorry about that! Glad that it's now working without the PW Info panel. I definitely need to make some optimizations there - I will try to take a look at this on Monday. It would be great to be able to replicate exactly what you have going on there, so I will probably come back with some more detailed questions for you. I am actually wondering about the PW Info panel in general and trying to figure out what elements of it you guys are finding most useful and whether some parts should be split into another panel so that those bits that are slow (due to loading large table fields for example) can be in a panel that you only load as needed using the "Once" option in the Selector Panel.

That is confusing that the errors persists with all panels disabled - is there any chance that you set a "sticky" set of panels that is overriding the settings in the module config? Closing your browser should clear the session cookie.

Keep in mind that post is very old. We now use $database: https://processwire.com/api/ref/database/ Beaten by @DaveP

I would start by opening the Network tab of your dev console and seeing what the path is - it should be something like: /processwire/page/lister/?session_bookmark=template_basic-page_pages&modal=inline&minimal=1 Take a look at the resonse tab for that request to see what is returned there. Then try loading that url directly in the browser and see what errors are displayed/logged.

Hey Macrura, What version of TracyDebugger are you running? Also, does it make any difference if you switch from the master to stable version of the Tracy core (in the module config settings). Also, what happens if you disable all the panels in the module settings. If it works with all panels disabled, please try enabling one at a time. I have a feeling it might be the PW Info panel - any chance you have a large Profields Table on these pages - I just came across an issue with this myself today - the PWInfo panel gets a LOT of data loaded in this situation. I need to figure out a way around this. Thanks for helping to figure this out.

https://processwire.com/talk/topic/8406-set-multiple-templates-role-access/?p=81711

Since you are playing around with mod_security settings, I would also try disabling it completely to see if that helps. Maybe also check to see if the server is running suhosin and disable that as well. If it works then you can work backwards to figure out what settings are needed.