adrian

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.

I can't see if you have anything selected for the login template in your settings - your screenshot is cut off. Is it definitely pointing to the login template php file? If it is, then we need to make sure the module is being loaded - can you add some debug statements to the module - I would start by making sure the "ProtectedCheck" method is being called: https://github.com/adrianbj/PageProtector/blob/master/PageProtector.module#L212 It would be great if you could get to see if it is called and then work your way through to make sure that this line: https://github.com/adrianbj/PageProtector/blob/master/PageProtector.module#L280 is being triggered. I would go with: wire('log')->save('debug', 'test'); or something similar to make sure each point in the code is being called. BTW - there is no need to manually create the login form on the login template page - just echo $loginForm and the module will take of that for you (but that shouldn't stop it from working). On another note - I see that you have the homepage protected - there is no need to protect any child pages separately unless you have specific roles assigned, but that doesn't seem to be the case - but again that shouldn't stop this from working.

@jrtderonde - I have never had a problem with it not working, so you'll need to help debug this. I find it weird that it worked until you restarted. Can you post a screenshot of the module config settings page and if you are using the login template approach, could you please post the code from that template.

Sounds good, but just so you know, Tracy can also log errors and dump variables to the console in both Firefox and Chrome. And on that note, there is also soma's Chrome PHP Logger: http://modules.processwire.com/modules/chrome-php-logger/

Very good point - I don't think I ever realized this. It doesn't look like there is anyway to detect an AJAX call without this header being sent, or by perhaps sending a get/post variable that you can manually check. Kinda makes it a bit of pain if you're not using something like jquery. So it looks like if you want to use PW's $config->ajax, or you have TracyDebugger running, you'll need to make sure that header is sent. DG from the Tracy core has asked me to write something for their Readme along these lines. Perhaps PW should also have a note in the $config->ajax section?