Jump to content

ryan

Administrators
 View Profile  See their activity

  • Posts

    16,772

  • Joined

  • Last visited

  • Days Won

    1,530

 Content Type 

Everything posted by ryan

  1. ryan
    Of course -- nobody ever needs to ask if they can ask. Just ask.
  2. ryan
    Sorry there was a typo in my previous code, and I'm pretty sure that's why it didn't work. You want to use getField() rather than get(). $ls_fieldgroup->getField('title', true); The reason for this is that getField() can return a field in context but get() can't (as it only has 1 argument).
  3. ryan
    Try this: $title = $ls_fieldgroup->get('title', true); $title->collapsed = Inputfield::collapsedHidden; wire('fields')->saveFieldgroupContext($title, $ls_fieldgroup); I could probably make this simpler from the API perspective (to work more like your code example), but only you and I have needed this capability so far.
  4. ryan
    Sorry I missed this before. Got your PM so replying here. I'm still having some trouble understanding the question, but think I follow a bit. It sounds like you are trying to use $pages->get() to retrieve a page via a path like /a/b/ where /a/ is an actual page and /b/ is a urlSegment. A path with a urlSegment in it doesn't resolve to an actual page except when requested from the browser. So you can't use the API to retrieve a page by path with a urlSegment in it -- you'll get a NullPage. You would want to use just the /a/ (the part that is actually a page) in your API call. urlSegments are just runtime things for you to branch from in your template. They don't represent physical pages to the API.
  5. ryan
    But there's a difference between integration and distribution. If it was really GNU compatible, then I could take Redactor and make my own version that just changes the name (RyRedactor), and then offer it available for use to anyone for free. At that point, people would no longer have to pay for Redactor. As a result, I think when they say "integration with open source software" they aren't telling the full story. But if we can find an example of another GNU open source software doing it, then we can follow their lead.
  6. ryan
    If you guys see another GNU open source licensed CMS using this, then I'll assume that means we can too. Perch isn't a GNU/open source, so they don't have to consider the issue. If there's a way to make it legal, I'll be glad to handle the dev side of making this Inputfield if others want to chip in to buy the necessary license. But just the fact that it's necessary to buy a license makes me think it's not technically GNU compatible... could land us in hot water to distribute it with PW. Another way to do it would be to make it a commercial module (like Form Builder) where it doesn't come with PW, but you can add it on separately. That way the distribution is controlled in the same manner as Redactor, which would keep it legal.
  7. ryan
    Me too, but I think this is either because we didn't have enough nominations in that category… Or there are multiple similar categories (Best Open Source, Best Free, Best Budget -- which could all be potential synonyms), to spread the love and give more platforms a shot. Seems like a good idea IMO. One CMS can say they are the best Open Source CMS, another can say they are the best Free CMS, and another can say they are the best Budget CMS -- 3 winners on equal footing rather than just 1. This seems to work given that there isn't much crossover in what's listed between the categories (except for Concrete 5, in the categories mentioned).
  8. ryan
    Really impressed how quickly you changed this Mike. I'm not familiar with this list.ly service but am glad to find out about it!
  9. ryan
    I think that URLs will be relative to the requested URL? So if the JS is loaded on page /contact-us/ then the code snippet above would be looking for /contact-us/img/arrow_up.png, which would be incorrect. One way you can get around this is to let PW populate them for you. In your document <head>, add this before any other <script> calls: <script> var rootUrl = '<?=$config->urls->root?>'; var templatesUrl = '<?=$config->urls->templates?>'; </script> Then you'd be able to do this: .scrollUp({location:"right",image_src: templatesUrl + "js/img/arrow_up.png",wait:100,time:300});
  10. ryan
    Also, curious if any other pages on your site load, or do you just get the homepage? If you can only get the homepage (which is what I suspect) this points to .htaccess being disabled or mod_rewrite not being installed. The first thing to do is to load the /.htaccess file and edit it, inserting some garbage at the top like "aljkealkjfaljkfa". Save and try to view your homepage. If you still get your homepage (as opposed to a 500 error message) then your server is not reading the .htaccess file. Your sysadmin may need to add "AllowOverride All" to your domain's configuration in httpd.conf.
  11. ryan
    File uploads are next on the to-do list here. I would estimate around the apocalypse or even closer to the end of the year.
  12. ryan
    Do you get paid for the sites that you would with PW? When you come to the forums to get help, do you limit your questions purely to development work that you are doing for free? I originally developed PW to help us all create better sites in less time, and with more fun. I'm hoping that PW is helping others to be more competitive in all ways, including financially. But recognize that PW did not come into existence on its own. Years worth of time and money has gone into making ProcessWire happen. If you are using ProcessWire to develop sites you get paid for, then you are profiting from ProcessWire. And that's fine with me, no ROI is expected or wanted--I've never asked anyone for anything. But it is disheartening to hear a user make a statement with the implications yours makes. Form Builder is not about making a profit. I don't expect that I will ever make enough on it to offset the actual time investment on it. My hope is that eventually it will be something where the community and myself have split the cost to create. If I wanted a profit, I would go make a Form Builder for WordPress or Drupal where the user base is large enough for that potential to exist. Form Builder is a tool that wouldn't exist if I had to fully self fund it. It's also an experiment to determine if I can reduce my client workload and substitute some of it with ProcessWire-related development that benefits all of us. But I can't substitute something that supports my family with something that doesn't. Form Builder is here to benefit you, not me. If you build sites for a living (or even a hobby) it's going to pay for itself the first time you use it. If you previously spent half a day building a form, now you can spend minutes and get a better, more secure and capable result that can do all sorts of things with the results it collects. Also want to note that Form Builder is something completely different from the original subject of this thread and I don't view them as similar products at all. Likewise, Form Builder is completely different from something like Zend Form or others like it. One does not preclude the use of the other and we should all keep more than one tool in our forms toolbox. I fully support Clinton's project and any others that benefit forms in ProcessWire. Forms are one of the most diverse and important aspects of web development. I feel very confident about the value of Form Builder in your toolbox, so have made it 100% refundable if you find it isn't for you (this type of return policy is pretty rare with digital products).
  13. ryan
    This forum makes code indentation nearly impossible to translate, but this is how I usually do it with an associative array: $a = array( "foo" => "bar", "bar" => "foo" );
  14. ryan
    These also aren't static, as modules can add anything here. For instance, the Page Clone module and Nico's Page Delete module. Though I do like the idea of having that parallel.
  15. ryan
    This is a quantity-based vote, so even with a perfect voting system of this type, I would still expect the results to be strongly weighted by community size over any other factor. But it's a real honor to be listed next to these other systems, all of which have been around a lot longer, and are far more known, than ProcessWire. But that puts us at a real disadvantage given our relative age and community size, so I hope that people don't take the ultimate results of this too seriously. But just being listed in this poll is a nice honor for ProcessWire and hopefully a way that more will discover ProcessWire.
  16. ryan
    Mike, thanks for setting this up. Glad to see that ProcessWire got listed in the nominations for best open source CMS and best budget CMS! One question that comes to mind as I look at the voting system (WP-Polls) is if it supports any one of these? Require a validated email address. Meaning the vote doesn't count till they submit it and click a link in their email confirming it. Require each vote to be associated with a facebook or twitter account. Require people to include a brief text review (a sentence to a paragraph) qualifying their choice. The reason I ask is because anything that doesn't add some kind of qualification is vulnerable to the same thing afflicting the opensourcems.com rating system, here's more details of the problem. To summarize, these systems (that determine uniqueness by IP and session/cookie) are easily manipulated by proxy servers and blind submissions. Adding a qualifier (like one of the above bullets) drastically reduces or eliminates the problem.
  17. ryan
    This is another way to accomplish it, perhaps more efficiently: $n = 0; $total = count($page->thingy); foreach($page->thingy as $data) { $n++; $data->isFirst = ($n === 1); $data->isLast = ($n === $total); echo $data->render(); } Your repeater_thingy.php template should now be able to compare against $page->isFirst and $page->isLast
  18. ryan
    Welcome to the forums Roderigo. You may want to check out Form Builder, which might accomplish a lot of what you are looking for here, and pretty easily. Though you can also do it without, but it would involve more traditional HTML form building. Either way ,I think you'll be happy with ProcessWire as a foundation for your needs.
  19. ryan
    I think I understand what's going on, though haven't stepped through the live code yet. But it looks to me like there's potentially an issue in PW's Fieldgroups::save function where it doesn't like to be called multiple times. It queues fields for removal and doesn't do the actual remove until you call Fieldgroup::save. That's what it should do. But as far as I can tell, Fieldgroups::save doesn't clear out the removal queue after it completes the save, meaning it may try to remove something that's already been removed if you are making multiple calls to it. Assuming I'm right about that, it's an easy fix to the core (and already made it locally), but for compatibility with current versions, try making this change: after your $t->fieldgroup->save(); in uninstallField add this line: $t->fieldgroup->removedFields->remove("name=$name"); does that fix it?
  20. ryan
    Most likely the page that had output formatting off had somehow loaded before the default output formatting status had changed. When you set $pages->setOutputFormatting(true|false); it only affects pages loaded from that point forward. It will not change the output formatting status of existing pages in memory. When you retrieve a page from $pages->get() or $pages->find() for example, it's going to see if it has a copy of it in memory already and give you that one before it attempts to load a new one. Though you can clear all pages it's caching (forcing it to load fresh copies) by calling $pages->uncacheAll(); However, I think the route that you've already taken is a better one, so wouldn't change what you've got.
  21. ryan
    Permissions aren't a static thing, so I'm reluctant to start adding more static columns of permissions to templates. Permissions are ultimately just pages and any number of unknown permissions can exist. I can't drop permission-to-role assignment because that's the basis of our RBAC, or any RBAC. It would be throwing out the baby with the bathwater. Connecting permissions to the templates (or pages) is just a way of saying where the user can apply a group of permissions that they have. This is an expected part of an RBAC, connecting a group of permissions with another entity for further qualification (whether a page, template or something else). That doesn't mean it's always easy to understand, and RBACs are never straightforward to understand at first glance, but they are powerful. We've attempted to make it more straightforward by separating out a few specific permissions in the template (page-view, page-edit, page-create, page-add) rather than just giving them 1 checkbox that applies all the page-* permissions present in the user's roles (as in most RBACs). But it's a balance of figuring out how far to go with it. If you start taking it to the extreme, then the purpose and power of the RBAC gets lost. Having page-view, page-edit, page-create, page-add in the template access is actually unnecessary for us, but it does reduce the quantity of permissions and roles necessary to achieve a particular access control scenario (which I think is a good thing). However, it's ultimately a tradeoff because it's limiting the power of the RBAC just by having it work that way (like Diogo found). But I think it's a balanced tradeoff because it ultimately reduces complexity, especially for those not familiar with RBACs. Currently, all the page-* permissions except for page-view are activated by page-edit as a kind of a parent permission. So if the user has page-edit, then any other page-* permissions they have get activated along with it. We've separated out page-create and page-add for finer control over those aspects. And we could continue separating out more like you suggested (the ones that are currently parented by page-edit). But I don't want to push further in that direction because I think it's fighting the RBAC and reaching further towards something that can't scale beyond a predefined set of permissions. Adding more columns of permissions in the template only solves it for one person's needs. Eventually WillyC will come along and want to assign page-yoda permission to a template independently of any other permissions. I'd rather go in the opposite direction and reduce what permissions can be assigned at the template (by default), but make it definable. Imagine going to Modules > Process > ProcessTemplate > [edit module settings] and selecting from an asmSelect which permissions should be assignable at the template level -- a nice power user option? That way we aren't presenting a giant table of checkboxes for the vast majority that do not need this, but we are giving the power-user option to those that do. After all, this is the first time I've ever heard of someone wanting to give access to sort children of a page without being able to actually edit the page. So it seems like an unnecessary level of complexity for most to have to consider these rare cases every time they setup template permissions. But if we give the superuser control over what permissions deserve this "assignable at template" status, then I think that lets us veer towards simpler and more powerful at the same time.
  22. ryan
    Given that we don't know what the user's fields or types will be ahead of time, there isn't really any way to document it with the Page class (that I know of). The function that handles this particular situation (setting a value to a $page->pageref) is FieldtypePage::sanitizeValue(). It is currently documented (with phpdoc) to indicate what it's for and all the values that it accepts and returns. But doesn't say anything like "usually you'd set a PageArray" because I don't think anyone is going to be looking here unless they already know the routes that setting a value to a Page takes. Ultimately, the best way to document this sort of stuff may be outside of the code itself and in online documentation specific to each Fieldtype. I think the cheatsheet is a great resource for this stuff. Though I don't think there's anything specific to the situation we're talking about just because it's one of those things specific to a FieldtypePage. So I think FieldtypePage probably needs it's own manual. That's what we're doing now. But I'm not sure how to communicate to someone that when they set (or get) a value to a Page, a lot of decisions go on behind the scenes. In our particular case of setting a $page->pageref, the path would be this (pseudocode): $page->set('field_name', $somePage); { // if 'field_name' is a custom field confirmed by the page's fieldgroup, use setFieldValue() $this->setFieldValue('field_name', $somePage); { // get the Field object $field = $this->fields->get('field_name'); // let the Fieldtype sanitize the value before setting it to the $page, i.e. convert Page|int|string|array to PageArray $value = $field->type->sanitizeValue($this, $field, $somePage); } } That last line is where the magic happens. The sanitizeValue will accept $somePage in various types, but always returns a PageArray back to the page. If it gets something it doesn't like, then it's either going to throw an Exception or refuse it (depending on what the Fieldtype author thinks is appropriate). Something similar happens when you get() a value from a Page, tough even more behind the scenes: $page->get('field_name'); { // if field_name is a custom field confirmed by the page's fieldgroup, use getFieldValue() $this->getFieldValue('field_name'); { $field = $this->fields->get('field_name'); $value = parent::get('field_name'); // check if it's already loaded if(is_null($value)) { // value isn't yet loaded, so load it $value = $field->type->loadPageField($this, $field); if(is_null($value)) { // if no value then set a default (like blank PageArray) $value = $field->type->getDefaultValue($this, $field); } else { // convert value to runtime type, like array of ints => PageArray of Pages $value = $field->type->wakeupValue($this, $field, $value); } } // if output formatting is on, let the fieldtype modify it for presentation (if it wants to) if($this->outputFormatting) $value = $field->type->formatValue($this, $field, $value); } } I'm not exactly sure how to document this beyond the pseudocode above, or if it even matters. I'd rather people think of it as just setting or getting values and everything works. But it seems like a separate page of documentation for each Fieldtype might help to answer some of the questions.
  23. ryan
    Taking a closer look now, and apologies but I haven't had enough sleep -- the parent is responsible for the order of children. So page-edit on the parent is a pre-requisite to being able to apply page-sort there. The order of children is considered kind of like a field on the parent. If it weren't, then the user with page-sort permission would be able to go sort anything they had view access to (which I'm guessing most of us wouldn't want). Though it may be feasible that I could make page-sort accessible if the user has page-add permission on the parent.
  24. ryan
    Those should be translatable, I'll update.
  25. ryan
    FieldtypePage will take a whole lot of different things: integers, strings, multiple IDs encoded in strings, arrays, a Page, a PageArray, etc. But the point here is so that it can accommodate various export/import and data abstraction situations. As an example, lets say you export a bunch of pages to a CSV file and one field has multiple page references (lets call it 'pagerefs'). The page references become a string like "123|456|789" in the CSV. When that CSV gets imported again, $page->pagerefs gets assigned the string value of "123|456|789" and it needs to be smart enough to know what to do with that. In ProcessWire, any page field can be represented in a more basic type like this. This is what enables a high amount of portability with the data for export/import and web service situations. But that doesn't mean it's recommended API usage. For API usage, you should treat it as the type you specified in the field settings, be that a PageArray or a Page. I'm not aware of anywhere else that this type of overloading would be possible. I also don't want to recommend these abstractions for regular API usage. This is purely for the benefit of behind-the-scenes portability and automation. I don't think it's so applicable outside of the context of a $page->set() situation.
×
×
  • Create New...