LostKobrakai

I recently finished my first bigger from start to finish ProcessWire website. It's a website for a local architecture agency which does lot's of the more prestige projects in my area. The image of the partners is still missing, but the rest is ready. I did the design together with a ex-fellow student of mine, the programming is completely done by me. The self-imposed challange was building something that does really cater to current standarts. Therefore templating is done with mustache. On the initial page request the page is rendered serverside, everything else works via ajax, as long as the history api is available. If not it's not even loading the whole templating stuff and pages are served traditionally. http://wunderle-partner.de/ Modules uses: ListerPro AdminCustomFiles Jumplinks MarkupSEO HannaCode ProFields: Multiplier

You're right you can't sort them by simple drag and drop of programs. If you need this you'd do it the other way around, prepare programs independent of users and assing them to the user template via a page field.

Why shouldn't it be sortable by user? But regarding "finding the right program" you can set up the program template to not only show it's title in the page tree, but also the users name.

That it's easier fixable is true, but a client can still break stuff if you depend on a page being present, that's what I meant.

If the client deletes a page it's gone, no matter how you call it . It's still better to not use id's as they are one timers, while a page that's called by context can be recreated and used further without changing the code.

It's like this: - Videos - Video - Video - Video - Fitness Programs - Program - Program - Program - Users - User - User You upload all the videos, than you create users and then you can create the program for each user. This program has some pagefield where the trainer can chose the videos for the program (e.g. videos) and a pagefield to select which user this program relates to (e.g. user). Then you can use selectors like this: $pages->get("template=program, user=$user")->videos; // Get all videos from this users program $pages->find("template=program, videos=$someVideoID"); // Get all programs featuring this one video

The more flexible way would be to use the user template only for "userdata" and just use a pagefield to link each user to a section of the page where his fitness program is located. This way it's easier if you later decide that maybe a user could have more than one fitnessplan or something like that. It's kinda like in object oriented programming: A fitnessprogram is an object and a user is an object (already the case in pw), so it's the easiest to structure it this way in the backend, too.

Have a look at this pull request: https://github.com/ryancramerdesign/ProcessHannaCode/pull/10

Oh yeah, I don't recall that access form correctly everytime. One would have to use hooks to limit a user from deleting only certain pages.

I think I may very well have been the fact that I updated my installation that fixed it for me. Hopefully we can get this sorted out soon, as it's poping up ever so often.

Items can only be deleted from a pagetable if the user has the rights to delete the page, which the pagetable links to. This can be set in the corresponding templates' settings.

Maybe try this before you save the page. I'm not that fluid in pass by reference and this stuff, but maybe the changes are to a variable, that does not get picked up by the page. $p->isChanged($name); This is the line that made me curious. I would also rather use getFile() as it's nicer / more descriptive than the array notation. $file = $field[$identifier]; Also did you take a look at the database, to be sure it's the part before the saving, that does not work?

In this case it would be good, so it can be directly saved to the variable, but it's not a necessity and it's your module, you decide what you do there. ProcessWire does also not return "$this" most of the time you chain stuff. // PageArray -> Page -> Pageimages -> Pageimage -> String $pages->get("id=1466")->images->eq(0)->url;

It's exactly whats written there: You've supplied credentials for your mysql database which don't let processwire authenticate. Therefore access to the database is denied. Check your username, password and databasename in site/config.php. If that doesn't help you can try using 127.0.0.1 instead of localhost.

Did you try OR groups? (project=1024), (project="") Also your error suggests, that it's doesn't have to be a problem with the selector itself. Does it work with just the id?

Sadly I don't have any tips for you. But I think there should be a more easy way to implement a default language change. I've been working on a clients site the last week and their site should really be german by default and english optional, but they implemented german as second language and you'll get errors all the time about missing titles and stuff as you're just filling in the german value, which is not the default language. I eventually have a tip for you. Did you refresh you modules some times? Maybe there's stuff cached that is preventing any change.

Most of the time a form or is a one time setup, so I just use the following and translate it with processwires on board language management. <label for="name"><?php echo __("Name"); ?></label> <input name="name" …> For the navigation, why don't you use a simple multilanguage textfield for each page's title?

I'd go with something like this: foreach($matches as $match){ foreach(["title", "body", "short", "keyword", …] as $field){ if($match->is("$field*=$q")){ $textposition_in_field[] = array($field => strpos($match->$field, $q)); } } } After that one can decide which textposition will be the most important.

I think it's kinda like this: Page -> Pageimages (/-files) -> Pageimage (/-file), just like $page->images->eq(0). You'll find the corresponding classes in the core folder. Also having a look at FieldtypeFile and FieldtypeImage wouldn't do harm.

Just use the labels of templates to name them more descriptively. The buttons below pagetables will always show the label and fall back to the name of the template if no label is defined. For the "add new" buttons, there are a lot of them in processwire. Most of them are there, because either the context provides the information about what will be added or the cms can not tell ahead of time what will be added. You can edit them with hooks, different ones dependent on which one you'll want to edit, but not via the admin backend. But this is not the thread to take about this in detail.

It should work that way. Here's a comment from Pagefile.php. Did you check the other parts of the function to work properly?

I'm actually not that big of a backend guy, so maybe it does only seem easy to me. You're right with the database being dependent on fields. I had that wrong in mind. But I still think, that the ability to add additional fieldgroups beyond the "root" one shouldn't be crazy hard to pull of. For me it would also not really matter how this fits any models or if the database uses less joins, I just know that predefined groups of fields and reusing them are something that ProcessWire does not pull of nicely by now. The only thing I'm not so sure about is, if adding a additional layer between fields and templates really is the key to more success (productivity / ease of management / …). Wouldn't we have the case that after including this layer people would come and suggest adding another layer, because they want another level of grouping, and we'll get in some kind of loop.

What you're describing is actually already kind of a part of processwire. In fact you do not add fields to a template per se, but to a fieldgroup. The only thing missing is the ability to link more than one fieldgroup to a template. If additional fieldgroups would get there own database table it should work quite well. I have thought about such a feature in the past, too. Maybe some day something like this will get integrated.

If you're using the current stable version then pages are the best way to take. If you're on the dev version you could also use the new fieldset options. It's a lighter alternative to creating pages just for providing options, but more flexible as the select dropdown module.

In neither. If you're editing the pageTable field there's a textarea "Table fields to display in admin" under the "Input" tab. There's the place to change the columns.