ryan

This is for the User class right? I only ask because I see a commented addRole() in the Page class, but not in the User class. Though the context here seems to be Users, since roles are on templates not pages. So I'm thinking we're talking about the User class, but let me know if I'm wrong. There are some updates that I need to make to the API docs throughout (though additions, not removals). I'm not remembering why I removed the addRole/removeRole from the User class, but I will add them back. It's not commented in my source. Can you paste in the commented function you are talking about? I'm just confused about why you've got it and I don't, so I want to make sure I'm not missing anything important. Btw, here's how to accomplish the same thing, though not as pretty as $user->addRole('rolename'); $user->roles->add($roles->get("rolename")); Titles are optional for roles already (you have the option to add it to the role template). But once you add a title field to the template, it's no longer optional. I figure that separate name and title are redundant until you have complex needs, which is why it's not there already. So I left it as something that you can add to your role template if you want it. When creating any kind of page reference, it lets you choose what you want to be the 'label' field. It will show you all the fields in the system, with 'title' being the first (default) as it's the obvious choice in most cases. But with a Role, unless you add a title field, you'd want to change it to use 'name' as the label field. Role and user are the only templates in PW that have no title by default.

The FieldtypePage won't present unpublished page references in it's output. That Inputfield that you are using there will show all pages that you have access to. The strikethrough on it means that it's unpublished and not ready to be used for presentation, links, references, etc. It'll let you select it (unlike other Inputfields), and actually it does get stored. But when it comes time to load it again, it gets filtered out. It does it like this at load rather than save because a page that was published could now be unpublished, and likewise a page added in the API that was unpublished could now be published. Perhaps it shouldn't show unpublished pages in that PageList, but I figured the strikethrough here was clear enough and didn't want to add to the code complexity of the PageList process (which doesn't even know it's been used as an Inputfield).

Check your settings for the 'fileimages' field. What is the "max number of files" set at? If it's set at "1", then you should be able to access the field like in your example. If not, then you should set it to 1 in order to make your example work. To ProcessWire, all file/image fields are multi-file fields (Pagefiles). But as a convenience, it converts them to a single file field (Pagefile) if you specify that the field will only allow a max of 1 file. So if I'm correct, you either need to set it to 1, or treat it as a multi-file field, like this: echo $inc->fileimages->first()->basename; or foreach($inc->fileimages as $file) { echo $file->basename; } Let me know if I'm incorrect about this. It has come up a couple of times, so I'm thinking about adding some more clarification/configuration options in the field settings.

This topic has been moved to Themes and Profiles. [iurl]http://processwire.com/talk/index.php?topic=162.0[/iurl]

This topic has been moved to Themes and Profiles. [iurl]http://processwire.com/talk/index.php?topic=186.0[/iurl]

This topic has been moved to Themes and Profiles. [iurl]http://processwire.com/talk/index.php?topic=252.0[/iurl]

This topic has been moved to Themes and Profiles. [iurl]http://processwire.com/talk/index.php?topic=507.0[/iurl]

This topic has been moved to Themes and Profiles. [iurl]http://processwire.com/talk/index.php?topic=498.0[/iurl]

Thanks for the update Soma! I look forward to installing this, and will be sure to update the module directory later today or tomorrow. Were you able to find a solution for the TinyMCE issue? NM, saw that you already answered this in the other thread.

I think the question here may be too broad. But if we take the 4 items above, and your desire for the simple API, the only one ProcessWire doesn't have at present is a revision system. So if those are the core requirements, then no doubt ProcessWire may be a good framework to build from. I think you have to look at all the features you want and then consider how long each would take you to build in the various different frameworks (like CodeIgniter, as you mentioned). You may (or may not) find that ProcessWire has more of what you need than other frameworks. You'll also want to look at the licenses of each to make sure that they are compatible with your intended usage if you want to re-license the work to anyone else. I'm not an expert on any frameworks other than ProcessWire, so can't speak intelligently on any other frameworks. My opinion is that most of what you want to do sounds fairly straightforward from a technical standpoint, but the 'Wiki' behavior and access and revision system is where most of the development time would likely be spent if building in ProcessWire.

Oops, looks like I messed up something last minute. Just committed the fix. Thanks for letting me know.

I don't know why but the download counts have never been accurate. I'll be in the lookout for a fix, but until then just ignore the download counters.

Thanks Pete these are great links! Dropresize sounds perfect for a few clients I have in mind. I will definitely use both Dropresize and Teamviewer... just wish I had them in the past.

Welome to the forums Ranyefet. Good questions, and sounds like a challenging and fun site to build. I think that PW is a great solution for most of your requirements, but there are a few that would give me pause, which I'll quote below: Since it sounds, looks and smells like a Wiki, why not use a Wiki? Actually I think I understand why not... your data requirements are more structured than my understanding of most Wikis. But I don't know the Wiki landscape very well. In PW, you can certainly do this, but you'll be doing a lot of the coding for the 'Wiki' behavior yourself. That being said, I'd love to see someone do this, but I don't want to underplay the scope of work that would involve relative to just using a Wiki. PW does not have this at present so you would have to keep your revisions stored separately from PW's live page data. This isn't particularly complex as an entire PW page can be represented as an array or JSON string quite easily. But again it does mean more code on your part. You could certainly do this in PW, but your requirements are pointing more towards a full-blown MVC framework or something built from the ground up. Personally, I would build it in PW because I wrote it and can generally make it do whatever I want more easily than other frameworks. But while PW is a framework, it's documented and promoted more as a CMS than a framework, and that's how most are using it. So if I were in your shoes, I would take a strong look at non-CMS frameworks like the Zend framework, CakePHP or maybe CodeIgniter, and consider them alongside ProcessWire in determining what will provide the best fit.

That's bizarre. I wouldn't think an SSD drive would make any difference, but who knows. I'm just glad to hear it's started working for you.

ProcessWire RSS Feed Loader Given an RSS feed URL, this module will pull it, and let you foreach() it or render it. This module will also cache feeds that you retrieve with it. The module is designed for ProcessWire 2.1+, but may also work with 2.0 (haven't tried yet). This module is the opposite of the MarkupRSS module that comes with ProcessWire because that module creates RSS feeds. Whereas this module loads them and gives you easy access to the data to do whatever you want. For a simple live example of this module in use, see the processwire.com homepage (and many of the inside pages) for the "Latest Forum Post" section in the sidebar. Download at: https://github.com/r...n/MarkupLoadRSS REQUIREMENTS This module requires that your PHP installation have the 'allow_url_fopen' option enabled. By default, it is enabled in PHP. However, some hosts turn it off for security reasons. This module will prevent itself from being installed if your system doesn't have allow_url_fopen. If you run into this problem, let me know as we may be able to find some other way of making it work without too much trouble. INSTALLATION The MarkupLoadRSS module installs in the same way as all PW modules: 1. Copy the MarkupLoadRSS.module file to your /site/modules/ directory. 2. Login to ProcessWire admin, click 'Modules' and 'Check for New Modules'. 3. Click 'Install' next to the Markup Load RSS module. USAGE The MarkupLoadRSS module is used from your template files. Usage is described with these examples: Example #1: Cycling through a feed <?php $rss = $modules->get("MarkupLoadRSS"); $rss->load("http://www.di.net/articles/rss/"); foreach($rss as $item) { echo "<p>"; echo "<a href='{$item->url}'>{$item->title}</a> "; echo $item->date . "<br /> "; echo $item->description; echo "</p>"; } Example #2: Using the built-in rendering <?php $rss = $modules->get("MarkupLoadRSS"); echo $rss->render("http://www.di.net/articles/rss/"); Example #3: Specifying options and using channel titles <?php $rss = $modules->get("MarkupLoadRSS"); $rss->limit = 5; $rss->cache = 0; $rss->maxLength = 255; $rss->dateFormat = 'm/d/Y H:i:s'; $rss->load("http://www.di.net/articles/rss/"); echo "<h2>{$rss->title}</h2>"; echo "<p>{$rss->description}</p>"; echo "<ul>"; foreach($rss as $item) { echo "<li>" . $item->title . "</li>"; } echo "</ul>"; OPTIONS Options MUST be set before calling load() or render(). <?php // specify that you want to load up to 3 items (default = 10) $rss->limit = 3; // set the feed to cache for an hour (default = 120 seconds) // if you want to disable the cache, set it to 0. $rss->cache = 3600; // set the max length of any field, i.e. description (default = 2048) // field values longer than this will be truncated $rss->maxLength = 255; // tell it to strip out any HTML tags (default = true) $rss->stripTags = true; // tell it to encode any entities in the feed (default = true); $rss->encodeEntities = true; // set the date format used for output (use PHP date string) $rss->dateFormat = "Y-m-d g:i a"; See the $options array in the class for more options. You can also customize all output produced by the render() method, though it is probably easier just to foreach() the $rss yourself. But see the module class file and $options array near the top to see how to change the markup that render() produces. MORE DETAILS This module loads the given RSS feed and all data from it. It then populates that data into a WireArray of Page-like objects. All of the fields in the RSS <items> feed are accessible, so you use whatever the feed provides. The most common and expected field names in the RSS channel are: $rss->title $rss->pubDate (or $rss->date) $rss->description (or $rss->body) $rss->link (or $rss->url) $rss->created (unix timestamp of pubDate) The most common and expected field names for each RSS item are: $item->title $item->pubDate (or $item->date) $item->description (or $item->body) $item->link (or $item->url) $item->created (unix timestamp of pubDate) For convenience and consistency, ProcessWire translates some common RSS fields to the PW-equivalent naming style. You can choose to use either the ProcessWire-style name or the traditional RSS name, as shown above. HANDLING ERRORS If an error occurred when loading the feed, the $rss object will have 0 items in it: <?php $rss->load("..."); if(!count($rss)) { error } In addition, the $rss->error property always contains a detailed description of what error occurred: <?php if($rss->error) { echo "<p>{$rss->error}</p>"; } I recommend only checking for or reporting errors when you are developing and testing. On production sites you should skip error checking/testing, as blank output is a clear indication of an error. This module will not throw runtime exceptions so if an error occurs, it's not going to halt the site.

I've only been able to look on my iPhone so far (and it's shattered screen), by what I can see looks amazing--beautiful site. Nice job Adam. I can't wait to add this one to the site directory.

Soma nice to see you working on admin themes! A very mysterious a spooky theme. My screen brightness must be too low because I can't hardly see anything at all here.

Just tested and can't duplicate this either. FancyBox is loading here when uploading image(s) to a field that doesn't already have them. On the other hand, if I upload images to a field, then disable Javascript in my browser settings before clicking on any images, Fancybox no longer works. ;D Soma check that you've got the latest commit from last week. GitHub stopped updating my Twitter feed for some reason, so if you were using that to monitor commits you might have missed it.

Not sure that I understand the problem well enough to suggest a solution here. I wouldn't think the height would matter. Though it's easy to get lost for a day trying to debug jQuery UI sortables.

That is interesting. I wasn't aware of that issue with MySQL tables... can't say that it's ever occurred here, so hadn't considered those potential issues. I guess we should go all lowercase. But doing so would break existing installs. So will probably will need to come up with a new config toggle for this.

Can't seem to duplicate here either. Need more info (or screencast?) on how to reproduce it.

No UML diagrams at present. I'll use UML when a client project calls for it, but don't personally find it helpful in my own (or others) work unless I don't know the language the code is written in. Too much of a code thinker I guess. Though I'm certainly not opposed to it and it it helps others then I'm sure it'll see a place in the code docs someday. Ultimately, understanding the class structure of PW is not necessary to use the API in full or develop modules for it. PW is really focused on delivering an external interface that doesn't require inside system knowledge. However, if you are interested, understanding the Wire, WireData and WireArray classes gives a solid foundation for understanding how everything in PW works.

The advanced mode is meant for PW system development, so it'll let you do things that aren't reversible in the API. However, advanced mode won't let you start removing permanent/system fields because then you really could break the system in a way that would be difficult to fix, even from the DB. In your case, you've added a system field, which is something different from changing the fieldgroup of a template. I think this will fix it: <?php $name = "name-of-template-you-want-to-fix"; $field = $fields->get("process"); // or substitute name of field you want to remove $fieldgroup = $fieldgroups->get($name); $db->query("DELETE FROM fieldgroups_fields WHERE fieldgroups_id={$fieldgroup->id} AND fields_id={$field->id} LIMIT 1"); With regard to advanced mode, I don't personally use it (or recommend using it) unless you are developing an addon module and need some advanced feature in a template or field that comes with your module. Advanced mode isn't meant for site development. I may need to clarify that more in the docs.

Like you said, the problem is that the database table is lowercase "_end" and the system thinks it's uppercase "_END". The question is where the lowercase version same from. I just tried creating some fieldsets but the tables are all ending up with uppercase _END as they should. Can you think of any other factors that might have resulted in the database table ending up with a lowercase version of the field? Thanks, Ryan