kongondo

What @horst said. As a btw, if in a module, you also have the option of $this->sanitizer

Hi @dps123. Welcome to ProcessWire and the forums. page URLs are formatted using the $sanitizer->pageName('Title of Page') function. Have a read here. Edit: Unless you are talking about the JavaScript that shows the live formatting as you enter the page title?

@AndZyk I don't think that's a good idea, at least not the first solution I would go for. There's a very good reason PW blocks execution of 'foreign' .php files in that folder. I don't know about the lcmini.php script but I would first consider the following: Convert it to a template file Use an include from within a template file

@pwired, I didn't hear you apologising to pocket-grid . Glad you sorted it out .

Aah, I see. If you need to use the template file of the child pages, have a look at this long thread. @jonathan's post may be of special interest in your case. You do not need to use the redirect module for such a simple redirect. For such you use $session->redirect('url') like I indicated . Have a read here about the session variable.

@Gazley, we can probably get around that. The main issue for me is how to reference the current repeater matrix item, basically the 'neighbouring' page field. In normal repeaters, fields are grouped (using their modified field-names) like so in one repeater item: email_repeater3157 page_field_name_repeater3157 runtime_markup_field_name3157 eq(0) email_repeater3179 page_field_name_repeater3179 runtime_markup_field_name3179 eq(1) What is needed is a way to get the eq(n) of the repeater or the 3157 (the ID of the page where the fields actually live - hidden repeater page in admin) Btw, $page->getForPage() won't cut it because this is the current page that has all those repeater items, in other words the $page in your RuntimeMarkup field. It seems the $page variable will do it? I don't even have a PW 3.x install ( ) which RepeaterMatrix requires to test this. Time, oh time...

Hi Peter, There's various techniques to solve this: Don't give the template of team-member-1 (the child pages) a template file. And decide what to do when that URL is accessed Don't give 'guest' view access (in template file of the child pages) and tell PW what to do when those child pages are accessed - e.g. redirect to some URL In the template file of child pages, use $session-redirect('/some-url/') to redirect users to the parent page Etc...(aka - please search - this has been covered a lot in the forums)

Maybe helpful? http://stackoverflow.com/questions/12609110/responsive-css-background-images Maybe some other (non-pocket-grid) nested div within div#top?

Btw, above answer refers to normal repeaters. I haven't used repeater matrix before. I am wondering whether, unlike normal repeaters, will be able to give you a 'current repeater item' variable. Anybody knows? Haven't got time to test atm.

A width of xx% auto-resizes to fit the available space. That's why pocket-grid uses percentages. So, give it a 100% width if you want it to fill the whole screen...but check if that affects your background-img and if you need to style that as well.

You mean like this? How about adding a (min)height to the div#top or whichever element has the background img?

How can the problem be pocket-grid? All it does is give you a width; nothing else. You can override its default 100% widths and give an element a 20% width, or 75% or 33.33333% or whatever....but you know this. So, width has nothing (much) to do with this. What you want to focus on is positioning and that's your custom CSS Do you have a graphic/drawing we can look at (btw, I am the last guy you should be taking CSS advice from - it's my weakest link! - but I stand by what I've said so far.. )

Tack!

As we wait for some code and/or graphic/drawing, I can say with almost 100% certainty that this should work with pocket-grid css. I use it everywhere . Remember that pocket-grid, actually, does, eh, nothing...or nothing much (seemingly). All it gives you out of the box are 100% width and float:left when you use the class .block. It sounds to me like you want to position some image absolutely. Shouldn't you be able to accomplish that with the normal parent element positioned relatively and the thing you want to stay in place positioned absolutely? Anyway, I don't need to tell you that pocket-grid does not get in the way of your CSS. It sounds to me like the issue is your CSS, not pocket-grid

@Gazley, I don't think this is possible out of the box. Have a read here at a similar question: https://processwire.com/talk/topic/8962-selectable-pages-defined-dynamically-for-page-field-in-repeater/ What you want is a way to get the current repeater item, basically the nth repeater. I haven't seen any way to do that without looping through all repeaters - which wont be very efficient. If your page field is a single page field, using a select, maybe we could use jQuery Ajax to dynamically send the id of the selected page to some template file which would then grab whatever it is you want from template 2, return that as JSON and dynamically add the markup next to the page field. I'm not sure, in your case, whether it's worth the effort going down that route.

I haven't tried this in a repeater...yet. so would have to do that before I can give an answer...unless someone beats me to it?

It could be as simple as having code like this in your RuntimeMarkup field settings for template 1 //pseudo code $out = 'No value entered'; if($page->name_of_single_page_field->title == 'whatever') { $out = $pages->get('/some-page/, template=template-2')->title; } return $out; If you have further questions let's take it at the module's support forum

I seem to recall something similar but can't find it now. You could consider using the module RuntimeMarkup using some custom JS to monitor select changes or if you don't want it to detect live changes just to display the output you want on save. Your PHP code could even reside in a file that you could access using WireRender(). It (the output) wouldn't really be 'adjacent' to your Page Field though

That's the sanitizer (filename) at work. From PW's point of view, it doesn't matter. It will get the correct file (it has been renamed). So the question really should be, does it matter on your side? E.g. Do you have another API outside PW or another APP that will expect your image files named using a particular format? If the answer is no, then it doesn't matter. If yes, I think Adrian has a file renamer module that can be configured to your heart's desire.

Yes, a plain textarea works best for this. I use the same technique in Menu Builder. Form Builder also stores data as JSON. Same as @tpr, the main disadvantage I see is searching. What's you rationale for 1 page per poll? Why not 1 page per question? With the former, it is a bit difficult to compare how a specific question was answered. I guess it all depends on what you want to do with the survey afterwards. I don't understand this. What are these child pages? What is their parent page? At the end of the day, it really depends on 1) scalability 2) what you are after. Are the individual users the main object of your study? i.e. are you mainly interested in what 'John' said as compared to 'Mary'? Or, are the questions themselves the most important thing, e.g. 'Drink A tests better than drink B', 'Car X is better than can Y'. Easier approach is not always best approach. When it comes to analysing your data you want that to be as most efficient as possible. It might not have been 'easier' to set up, but it will provide a more meaningful insight into the data (plus maybe easier to maintain) than the 'easier' way . I guess what I am saying is that it's hard to give a definitive answer because it's not clear what you want to do with the data in the end (and also how you want it maintained). The answer to that/these question(s) might mean it is better to use pages instead; or it is better to use JSON or even custom SQL tables. Just my 2p

You mean 'thank you'....

Did you save?

$t->flags = Template::flagSystemOverride; $t->flags = 0; // etc... save here or delete $t->save();

@robsns, Welcome to ProcessWire and the forums. Are you saying that you have a single (1) page with a custom field (based on FieldtypeEvents) that has ~18 columns and there's 6000 event entries (rows), i.e.., 6000x18 in total? Difficult to give a specific answer to your question since not clear why you have to have all these courses in 1 page. There could be other options, e.g. using a Process Module, or separating those 6000 courses into different groups, etc. If you want to discuss further, please start a new topic (since your question is not really related to FieldtypeEvents but a different custom module) and we'll take it from there