kongondo

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

You would have to do it either manually or using the API. If it's only a few pages to deal with you could do it manually. Otherwise, use the API. Something like this. First, rename your current text field 'views_count' to something like 'views_count_old' Create an integer field called 'views_count'. Add it to your template (the one with pages requiring view counts) Backup your db Run the code below in a template file (doesn't matter which one) on a test install first if you can. If all goes well, run on your 'real' install If all went well, remove 'views_count_old' from the above template @note: Written in browser and haven't tested but it should work. If you have thousands of pages you will want to do it in batches foreach ($pages->find('template=template-with-views-count-field') as $p) { $p->of(false); $p->views_count = (int) $p->views_count_old; $p->save('views_count'); }

Hi @Hantsweb, Glad you like the module. Technically, you can't 'attach' the module to a field in one of your templates . But I think I get what you are saying. You want uploaded files to be added to a field on some page(s). Before I dive into an answer, I hope in your upload implementation you've remembered to...'never to trust your users',...especially those who are allowed to add things to pages and whether what they've uploaded is immediately viewable on the frontend . Yes, the module does very thorough validation and will only upload what you've allowed to be uploaded but its always good to double check. Below are links to some code I've previously posted that will be of help. What is your workflow? Are user uploads immediately added to a page? Are there unique pages for each user? Are compressed files (zip) in play? Whatever the answer to these questions, the basics are the same: Upload files to your server to a specified temporary folder(s). During the process validate the files: JqueryFileUpload Iterate over the folder with the uploads: I always use PHP SPL class for this, e.g. RecursiveDirectoryIterator In each iteration, add valid files to specified pages (if those pages are not being created by the uploads): Use ProcessWire for this Delete uploads in the temporary folder Example code: https://processwire.com/talk/topic/10815-mass-create-pages-or-mass-upload-images-and-thus-create-pages/?p=101791 https://processwire.com/talk/topic/8416-importing-many-pictures-in-a-page/ If you are adding to files to pages directly after they've been uploaded, you will want to listen to Ajax requests sent by JqueryFileUpload like so: if ($this->config->ajax) { // you code here for iteration, creating and/or adding files to pages } Let us know if you hit another brick wall

@joer80, I split your post (and replies to it) into a new thread since it was going off on a tangent in relation to the contents of this thread. The new thread (couldn't find an apt title - feel free to change it) can be found here: https://processwire.com/talk/topic/12765-distinct-pages-api-split-topic/ Let's continue your discussion there.

Brilliant! Thanks. I was on a very old version

I am having the same problem (also using paypal sandbox)

Without changing the admin theme code (JS and/or CSS?), I think @Martijn's JS admin module could do the trick. I can't seem to remember its name atm...I'll check then edit this post Edit: The name is Admin Custom Files http://mods.pw/7i https://processwire.com/talk/topic/7588-admin-custom-files/ Edit 2: Or use the Reno Theme

Hmm. It's not as straightforward as that. I was planning this as a commercial module so there are long term economic considerations to take into account. I am ready to listen to different proposals (and maybe we should start a new topic) about the way forward. What I have been working on is a full-blown calendar with a couple of bells and whistles - reminders, multiple calendars, categories, tasks, contacts, etc...the works...basically, a suite of features that a modern day calendar should have (but without going overboard with features to rival desktop alternatives ). We have a couple of alternatives to consider. Don't change a thing; go ahead as planned Fully funded by community - released for free to the community Fully funded by community - available for sale at a subsidized price Fully funded by community - released for free but with paid support Fully funded by community - initial release free, paid for upgrades Other variants of above, etc...