ryan

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

Okay I see what you mean and think that makes sense. Though I still don't want the core taking any actions on this, as I just don't think there's any way for the core to know the developers intentions here. But I have no problem coding options into the MarkupPagerNav module. It does make for a more complex API, but it's also one of those things that's optional so not concerned about adding it. I'm thinking the options should be: MarkupPagerNav::outOfBoundsNone = 0; MarkupPagerNav::outOfBounds404 = 1; MarkupPagerNav::outOfBoundsRedirectFirst = 2; MarkupPagerNav::outOfBoundsRedirectLast = 3; Example: <?php $matches = $pages->find("..."); $pager = $matches->renderPager(array('outOfBounds' => MarkupPagerNav::outOfBounds404)); if(count($matches)) { echo $matches->render(); // or however you want to output echo $pager; // note $pager has to be generated before output since it may send 404 or redirect headers. } else { echo "<p>Sorry no matches</p>"; } Until we have such options, here is how you are supposed to do it now: <?php $matches = $pages->find("..."); if(count($matches)) { echo $matches->render(); // or however you want to output echo $matches->renderPager(); } else { if($input->pageNum > 1) throw new Wire404Exception(); echo "<p>Sorry no matches.</p>"; } Or if you are lazy like me and don't care too much about out of bounds: <?php $matches = $pages->find("..."); echo $matches->render() . $matches->renderPager(); if(!count($matches)) echo "<p>Sorry no matches.</p>";

I got it–understand now. I think that's a good idea, will plan on doing this.

I don't mind adding some more markup or container(s) if it helps with theming. I'm not sure I follow exactly what's needed here, but it should be easy enough for me to add–just let me know where.