MindFull

Maybe I'm reading your question wrong, but maybe try manually adding a '/' in your href when rendering the pagination $pagination = $selects->renderPager(array( 'listMarkup' => "<ul class='MarkupPagerNav pagination'>{out}</ul>", 'currentItemClass' => 'current' )); echo $pagination; echo "<ul>"; foreach($selects as $select) { echo "<li><a href='{$select->url}/?sort={$sort}'>{$select->title}</a></li>"; } echo "</ul>"; echo $pagination;

Did you figure out what you needed to do? I've implemented Datatables many times with ProcessWire and your site structure seems very easy to build. So if you're still in the dark let me know.

I like it, it has a nice UX feel when scrolling with the mouse. FYI, took it for a spin on my Windows machine to see if I could find the flicker Teppo's seeing but couldn't get it to reproduce in FF or Chrome.

I don't think that's the problem. I think you're having issues here: <?foreach ($page->children as $c):?> and <?foreach ($page->children as $directors):?> They are the same loop, with the same set of children being iterated so it makes sense that every time you add a directors page you get another box being drawn, but it's empty because your fields (with the exception of image) are named differently. Try using a selector to specify the template. Maybe: <?foreach ($page->children("template=staffCardTemplate") as $c):?> ... Rest of Code <?foreach ($page->children("template=directorsCardTemplate") as $directors):?> That way your code only grabs children of the appropriate template when iterating.

You could just test the page's created user against the current user. Using your code: if($input->post->delete) { $deletePage = $input->post->delete; $id = (int) $deletePage; //sanitize post value to integer $p = $pages->get($id); //get this one page whose ID was sent over using its delete button $title = $p->title; // TEST IF THE CURRENT USER IS THE PERSON WHO CREATED THE PAGE if($p->createdUser == $user){ $p->trash(); echo '<div data-alert class="alert-box success radius"> The post ' . $title . ' was successfully deleted! <br><br><a href="/profile" class="button small secondary" style="color:#000;">CONTINUE</a> </div>';//there are better ways to check! } else{ .......DO SOMETHING ELSE HERE } } I do think these posts should try to stay along the lines of the original topic, so as to not clutter this very useful thread.

Unfortunately, yes. I don't like it but some of the folks we work with won't/can't make such simple decisions without at least 10 of their higher-ups agreeing on it first. Oh the joy...

English confused me so much, that I when I finally made heads and tails of it, I had forgotten my native language

I do, all the time in jQuery But yeah, traversing an array manually in PHP with each() is a random occurrence for me too. Used in conjunction with list(), it's slow and fickle. foreach() FTW

I think, more than anything, Diogo and Martijn are highlighting to you the importance of semantics and syntax within your code: though the syntax produces a result, even one you might be able to work it, it's semantically confusing, implicit, and error prone. I know you're just testing the code, please don't think anyone is trying to badger you. Test, play, code all you need to in order to grasp the API. I think everyone just wants to help you get these small concepts and keep them in mind because they are important.

I don't think the pages being subdivided by state is a bad approach, it provides you with some extra organization in the back end. In all actuality, just create a new parent page ie USA and place all the states underneath that. Now when you expand to other countries, just create a parent page for each country under your home page and categorize children according to province, district, county, city, etc. I think it's a sensible choice you made that can be expanded on rather easily. As far as the module for directory listings, as far as I'm concerned, PW has a very suitable back-end for such sites and since implementation is as simple as displaying children of the parent page based on whatever condition you desire, I can't see where a module could add much more simplicity except on a use case basis. But by the time you cover those, you'd have an entire library of directory listing modules. Good job on the site. I like its ease of use.

You, my friend, are getting it! IMHO, your approach is probably one of the best ways to learn an API, play with the code! It only gets better with PW.

Do not go down that road, it is a dark and miserable path where fellow travelers seek to fill your pages with a contagion of confusion and dismay. Aside from the occasional notion of "oh, this might actually work", you will find yourself subject to the chains of their template systems. At the end of the day, though your site may work, you may cringe at the mere mention of changing anything in it. And it only gets worse as your projects become more involved. (Speaking from experience.) Stay here, it's nice here.

Love the feel of everything. Well, almost everything: support dialog boxes bother me, but that's more a me thing than anything else. And where's the balut on the menu? J/K Good job on the site, when I vacate next January, I'll order something and give you some feedback. Will the deliveries make it out to Olongapo?

If you look on the cheatsheet, right below $a[$key] is $a->$key. If you want to translate that to your current page you could simply replace $a with $page. Or in your code example, $item. So you have: $a->$key is the same as $item->summary: $a is the page ($item) being referenced, and $key is the index or, in this case, the field name (summary). According to the cheatsheet: $a->key returns the VALUE of the item at the given $key. Therefore, $item->summary returns the string that you have in a text field. But look at what happens with $item->myfield: myfield is a PageArray and title is a field: Translates to "return the value of the PageArray at the given field title". PageArray's don't have title fields, pages do. Therefore iteration is required to access the title field of each page in the array referenced by myfield. It's easy to over complicate PW's API. You have to be mindful of its syntax, the usage of the variables/methods available, and the return values of the methods being used or you will in for a bumpy ride: and that's with any API you decide to use.

Your "summary" field is not a PageArray, therefore, you can't really iterate through it as one. Hence the reason it's "gone". The "my_select" field, if it is a Page Field, can be iterated, therefore the loop grabs the title. If you wanted to determine if the field needs iterating, you could do a simple count. If the # of objects that count finds is greater than 1, you've got to iterate. Using your code: // render optional extra fields wrapped in named spans if(count($options['fields'])) { // Iterate options['fields'] array foreach($options['fields'] as $name) { // If the page's field returns more than one object if (count($item->$name) > 1){ // Iterate the PageArray referenced by the "my_select" field foreach($item->$name as $pageField){ // Grab title $out .= $pageField->title."<br/>"; } } else{ $out .= "<span class='$name'>" . $item->$title . "</span> "; //Or whatever you want to do } } } Definitely not the most elegant solution but it highlights some important aspects of PW fields. In order to iterate through the "sub"-fields of a field set as a Page Field type: you must iterate through those pages. And for a field that would be returning just a string or numeric value, like your $page->summary, you simply return that value to wherever you want it to go. I wasn't 100% sure what you were trying to accomplish but I hope this helps you over that little hump.

If you want, I can PM you my email: so we don't clutter your job posting with code snippets. I have a general understanding of what you need and though I might not be a "solid" developer, I'm good enough to be employed by some. I honestly don't know if I have the time to commit to a whole other project right now, I spend most of the day & night punching a virtual time card trying to finish an application for work. PS, it's really hard to see what you're doing/not doing without seeing some of your code, lol. Maybe start a thread in General Support and post some code? If not, you have a PM, sir.

The index.php file goes into where ever you've put you main website directory, so if my website directory is called "mywebsite" and it's in the "public_html" directory of the server you would put the index.php file: public_html/ mywebsite/ index.php //here is where you would put it Are you using shared hosting or do you have root access? I guess I should ask: are you using Apache or IIS? BTW, I like the duck... birds of a feather, code together

Lol, my experience with most HelpDesk guys (including friends that work in the field) is they know enough to pretend they know it all. aMember has a script (plugin) for other CMS's including WordPress and Joomla. If they can do it, so can we, ugh... you! After all, it's more a matter of mapping database fields then anything else. You would create a script that grabs the aMember data on login, validate the subscription, if all is good, pass it to PW. Firstly, if you don't mind me asking, what does your include() look like on aMembers side? It should be the absolute path from the server root to PW index.php

From this, I'm gathering that most of your directories in /files actually contain either images or files. And though you just cleared out the empties, you're going to be hitting your max again soon. You need a way to circumvent Apache's file limit within any directory, like have a /file2 directory where new pages can store things. Correct?

Now that, I could not tell you - I have no access to form builder code and have never seen the module outside of the video demo. It would make sense to include a file with this sort of thing wrapped into a function/hook so as to keep the code you're adding separate from the module, for updating/upgrading purposes. Can't sleep... Assuming you would like to add it as a hooked method you could do something simple like: // Attach the hook in the FormBuilder Class $this->pages->addHookAfter('save', $this, 'hookAfterPageSave'); //Define what you want to do after the page is saved function hookAfterPageSave($event) { // argument(0) is the current page on the save $event $anEditablePage = $event->arguments(0); // add the page to editable_pages field (if in FormBuilder Class) $this->user->editable_pages->add($anEditablePage); } This would do essentially the same thing but the FormBuilder class, (or whatever it may be called), would run this method on page save. Look here: http://processwire.com/api/hooks/ for details on how hooks work. Again, the code is coming out of my 3am brain: so no warranty that any of it works.

I am so glad those weren't on any of my spelling tests...

Great to hear you're making progress. The Page Edit Per User adds a new field to every users' page; it's name is editable_pages. This is a Page Field and behaves like any other so to add a value to it when the user creates a page with the form-builder you could do something like: // Get user that made the page $owner = $page->createdUser; // If this is the same user: (Should be on page creation, but anyway) if($user == $owner){ // Turn off outputting formatting for user's page $user->of(false); // Add this current page to the editable_pages field $user->editable_pages->add($page); // Don't forget to save the user's page $user->save(); // Turn output formatting back on $user->of(true); } Just remember that the page created by the using the form builder must have been saved before you can add it to the user's editable_pages field. For clarity purposes: Users in PW are Pages. So accessing the user's fields would be like any other page's field. I haven't used the module but I'm pretty sure you could dynamically add pages to this field with the API as shown in the pseudo-code. Keep at it, you'll get it. BTW: I saw this in the Modules Section: http://modules.processwire.com/modules/schedule-pages/ and thought you might be interested in checking it out, does pretty much what I was demonstrating a couple of posts up.

BTW, I saw your thread @ https://processwire.com/talk/topic/5735-membership-subscription-payments-general-pw-support/#entry58940 and I think once you get over this hurdle, things will get easier with integrating PW into aMember since the PW api is so easy to use. If I still used aMember I would try this myself, I think it would work really well.

http://manual.amember.com/Protection_Methods At the bottom of the page: To enable htpasswd plugin, follow instructions: Visit aMember CP -> Setup -> Plugins and enable htpasswd in Protection Plugins list. Click to aMember Cp -> Rebuild Db to build .htpasswd and .htgroup files in amember/data/ folder, else protection will not work until Midnight. Lol, I don't know how helpful that bit will be if you can't get into the CP.

Also, check if your Protection Method is New_Rewrite or Mod_Rewrite, I know the Mod_Rewrite can cause issues with non amember scripts. Also, if you have either New_Rewrite or htpasswd as your method, you won't get many logs. I think New does logins and htpasswd logs nothing