ryan

To literally extend the images field to have more inputs, you would have to make your own Fieldtype/Inputfield to support. See the file attached above (in one of my previous posts) for an example of that--it does take some PHP. Most likely we'll add built-in support for extending the image/file fields in the future (i.e. something you could configure with the field settings). Another approach that some use is to create an 'image' template with one image field, and all the other fields you want to be grouped with an image. Then each page serves as an image with whatever metadata you want. At small scale use, this may be less convenient to manage than having an image field with it all built in. But it is more powerful and scalable to use this approach.

E-mail notification? I'm still not getting them, except for direct messages. Did you do anything to get it?

WillMorris, Very likely ProcessWire will be a good fit for your need. That bird site would be an excellent example of where ProcessWire does well. When it comes time to build your "taxonomy" post the full scenario here and we'll guide you through the best approach. ProcessWire tends to be very flexible in this regard, and that means that some ways to approach something are better than another. For instance, it would be possible to build this taxonomy in a way that's not very efficient, and likewise possible to build it in a way that's highly efficient. When it comes to building for the large scale, you have to be more careful with approach in order to ensure you aren't accidentally loading 6k pages in 1 API call (as Adam mentioned). Taxonomy is such an unfortunate term. It has a strong resemblance to the term "Taxidermy", which in English means the "art" of creating life-like stuffed animals out of dead animals. Not a mental picture I like. This is why you don't see me use the term taxonomy very often.

For that type of multi-site setup, the way that I do it, and I think others are, is to just use symbolic links. So all the sites share the same /wire/ directory, but each have their own /site/ directory. But lets say you've got just one hosting account and want to run multiple sites at the same web root. In that case you need to adjust the config according to the hostname. This is easy to do. Edit your /index.php file and locate this line: $siteDir = "site"; ...and add this after it: if(strpos($_SERVER['HTTP_HOST'], 'other-site.com') !== false) $siteDir = 'other-site'; Admittedly I haven't had a need to try it just yet, but that's the way it's meant to work. So in the above scenario, if someone access your site at 'other-site.com', then it uses the 'other-site' directory rather than the 'site' directory.

When you have more than 50 children, ProcessWire starts paginating them in the admin. Anything that has large numbers of children should generally have a default sort assigned to it (like date). I work with several sites that have thousands of pages and ProcessWire is specifically built for this sort of scalability in the admin and the API.

All the redirects from the old (SMF) forums to the new (IP.Board) forums are now in place. This includes all the boards and topics. You can take any URL from the old forums (http://processwire.com/talk_old/) and replace the 'talk_old' in the URL with 'talk' and it should redirect to the right place on the new forums. This includes boards, topics, and even pagination within topics. Just in case anyone is interested (Pete?) I'm going to post how to do it, as I'm guessing someone, somewhere will eventually have this need again. And even if nobody is interested, I'm feeling proud of myself and want to type about it. Redirecting all SMF boards and topics to IP.Board (IPB) First, I added the following after the 'RewriteBase' line of IP.Board's .htaccess file: RewriteCond %{REQUEST_URI} ^/talk/index\.php/(board|topic), RewriteRule ^(.*)$ /redirect.php?it=$1 [L,QSA] That basically says: Match any URLs that look like /talk/index.php/board, or /talk/index.php/topic (i.e. SMF style URLs), and send them to my PHP file called /redirect.php (rather than sending them to IP.Board). It sends the URL that was requested in a GET var called 'it' (this is the same method ProcessWire uses). So now that we've got the URLs pointing to our /redirect.php file, we have to make the redirect.php file. Here it is (below). I'm matching the board URLs statically (with a translation array) since there are so few of them. For the topics, I'm going into both the SMF and IPB database and matching them up based on post time and subject. <?php // if redirect.php accessed directly without 'it' get var, then abort if(empty($_GET['it'])) exit(); // static redirects for SMF boards => IPB boards $redirects = array( 'index.php/board,6.0.html' => '/talk/forum/7-news-amp-announcements/', 'index.php/board,7.0.html' => '/talk/forum/8-getting-started/', 'index.php/board,1.0.html' => '/talk/forum/2-general-support/', 'index.php/board,5.0.html' => '/talk/forum/6-faqs/', 'index.php/board,12.0.html' => '/talk/forum/13-tutorials/', 'index.php/board,2.0.html' => '/talk/forum/3-api-amp-templates/', 'index.php/board,3.0.html' => '/talk/forum/4-modulesplugins/', 'index.php/board,11.0.html' => '/talk/forum/12-themes-and-profiles/', 'index.php/board,4.0.html' => '/talk/forum/5-wishlist-amp-roadmap/', 'index.php/board,8.0.html' => '/talk/forum/9-showcase/', 'index.php/board,10.0.html' => '/talk/forum/11-pub/', ); // 'it' contains the URL that was attempted $it = $_GET['it']; // initialize $location, where we will store our found redirect URL $location = ''; if(isset($redirects[$it])) { // see if we have a board that matches our array, so use it $location = $redirects[$it]; } else if(preg_match('/topic,(\d+)\.(\d+)?/', $it, $matches)) { // URL matches the format like: /talk/topic,1234.html (and similar) // so we'll connect a SMF topic ID to IPB $topic_id = (int) $matches[1]; // get the optional starting post number (for pagination) $start = isset($matches[2]) ? (int) $matches[2] : 0; // get the SMF database $db = new mysqli('localhost', 'user', 'pass', 'smf_database'); // find the subject and posterTime from the SMF topic ID $result = $db->query("SELECT subject, posterTime FROM smf_messages WHERE smf_messages.ID_TOPIC=$topic_id ORDER BY posterTime LIMIT 1"); if($result->num_rows) { // found the SMF topic list($subject, $posterTime) = $result->fetch_array(); // sanitize for query $posterTime = (int) $posterTime; $subject = $db->escape_string(trim($subject)); // connect to the IPB database $db = new mysqli('localhost', 'user', 'pass', 'ipb_database'); // retrieve the ID and title_seo from IPB that matches the posterTime and subject $result = $db->query("SELECT tid, title_seo FROM ipb_topics WHERE start_date=$posterTime AND title='$subject' LIMIT 1"); if($result->num_rows) { // found it, build the redirect URL list($id, $title_seo) = $result->fetch_array(); $location = "/talk/topic/$id-$title_seo/"; // add the starting post number if we're redirecting to a page number if($start) $location .= "page__st__$start"; } } } // if no location was found, just redirect to the forums index if(!$location) $location = '/talk/'; // perform the 301 redirect header('HTTP/1.1 301 Moved Permanently'); header('Location: ' . $location);

You are on the right track Here's an example that does everything. It lists all the categories, and then lists all the entries within each category. This may not be something you actually want to do, but I'm putting it here as an example that can be translated to different contexts. It assumes your blog entries have a page reference field names "categories" and a date field named "date". $cats = $pages->get("/blog-categories/")->children(); echo "<ul>"; foreach($cats as $cat) { echo "<li><a href='{$cat->url}'>{$cat->title}</a>"; $entries = $pages->find("parent=/blog/, categories=$cat, sort=-date"); if(count($entries)) { echo "<ul>"; foreach($entries as $entry) { echo "<li><a href='{$entry->url}'>{$entry->title}</a> {$entry->date}</li>"; } echo "</ul>"; } echo "</li>" } echo "</ul>";

I'm working on 301 redirects and hope to have a solution in place today.

Nice job Marc! You've captured the place well and it makes me want to visit. Northern CA is my favorite part of the US. Nice colors, textures, and very readable throughout. Also like the food overlays in the nav rollovers. Are you doing a mobile version for this one too?

Thanks to Pete for all his great work in getting this converted and setup! As you can see, most avatars didn't convert over. Since IP.Board makes pretty heavy use of them, please update your profiles when you get a chance (I see you guys above already did). If you need to grab your old avatar pic from SMF, it's still up at running for a few days at http://processwire.com/talk_old/ We'll work out any more details over the coming days (stylesheet tweaks, etc). Let me know if you come across any errors. We had one issue with a corrupted file that we had to replace, so it's possible there are more. But hopefully not. I'm excited to learn all the features of this new forum! Hope that you all like it too. Thanks again to Pete for making this possible!

Just wanted to give you guys a heads up on what's going on this week (in order of occurrence): New Forums The forums software is moving from SMF to IP.Board. SMF has been very good to us, but with ProcessWire growing quickly we figured it would be a good time to take the forums to the next level. IP.Board will give us a lot more capabilities than we currently have, while maintaining the same ease of use. I looked at a test version setup by Pete, and I think you guys are going to love it. All of your existing login info will stay the same and all the posts will carry over, etc. It's possible you may lose your profile pic, in which case you'll need to replace it. This change might take place as soon as today, but we haven't decided for sure yet. Let me know if you run into any bugs or issues with the new system once we're up and running. Going live with ProcessWire 2.2 I'm going to be merging the ProcessWire 2.2 source into the stable branch (P21 master) this week. The optional LanguageSupport modules that come with it will still be considered beta. If you are tracking the source with Git, then the PW 2.2 update will come in automatically. If you are downloading the ZIP, then you'll just need to replace your existing /wire/ directory and /index.php file in order to apply the update. PW 2.2 now includes a "page-create" permission on the Templates > Edit Template > Access tab. If you are making use of any non-superuser roles that are able to edit pages, you will need to check the box on any relevant templates to add page-create permission for them. To word it differently, ProcessWire now wants you to tell it which templates a given role is allowed to use when creating a new page. If you don't do anything, than any non-superuser roles that can currently create pages won't be able to until you give them that page-create permission on at least one template. Please let me know if I can provide any more detail here, and I'm happy to assist anyone individually with this too. We won't put out a press release or officially announce ProcessWire 2.2 until the LanguageSupport modules are out of beta and we have some other promotional materials ready. But I don't see any reason to delay making PW 2.2 the stable branch in the source code.

Thanks for posting, nice site Transpix!

This is correct, $page->httpUrl is what you are looking for, and it will include the port as well. It will also account for https if the page in question is configured to use https from its template settings. The equivalent of $config->urls->root that you are looking for then would be: $pages->get('/')->httpUrl; Just note that it has to be accessed at it's URL in order for it to know it. So if you are working with the command line API, it's not going to know it...

I checked and there isn't currently a way to detect the status change from unpublished > published. Unless your module keeps track of it on its own by monitoring the status at load and save. So I'm going to put adding a Pages::published() on my to-do list, as it looks like it's something we need. Shorter term, what you are currently doing Nico is one way to accomplish it. But note that's only going to detect it interactively, and not for other API usage (which may be fine). I would just suggest changing this line: $db_page = (($this->pages->get('id='.$_GET['id']) instanceof NullPage) ? false : $this->pages->get('id='.$_GET['id'])); to this: <?php $db_page = wire('process')->getPage(); if(!$db_page || !$db_page->id || !$db->page->editable()) return;

Thanks for the update Nico!

MadMimi (love the name) looks pretty cool. I enjoyed watching this, thanks for the link! I'm not sure I understand how (or if) it solves the issue of an image being deleted somewhere else. But it's a beautiful example of editing and I like the way they are going about things there. I don't think it is necessarily a substitute for TinyMCE, but it seems perfect for what they are using it for. Rather than a rich text editor, they are using Markdown combined with <a href="http://markitup.jaysalvat.com/home/">MarkItUp</a> (I think), which is a great editing tool and one I'd really like to build an Inputfield for.

Thanks for the great feedback, that's very kind of you! We are glad to have you here. As for promoting ProcessWire, we always appreciate links, mentions, tweets, etc., where appropriate. ProcessWire isn't yet widely known, so basically anything that helps to get the word out.

Nico are you still working on this? I'm intrigued by the possibilities with this module–keep up the great work here.

Sorry I forgot to put that in the example, I've updated the example to include it.

This is the correct behavior. Not ideal I know, but that's also why it's best to use this particular feature carefully. The issue here is that TinyMCE saves a bunch of HTML markup, and that markup can feasibly have anything in it (images and links on site or off site). ProcessWire doesn't know anything about the markup that TinyMCE is saving. When you add an image in there, you are essentially adding an <img> tag like in any other HTML document, and the same rules apply. If you pull images from other pages (for TinyMCE), it's best to setup a shared 'gallery' page (or pages) designated for the purpose and you generally assume that all those images are in use until proven otherwise. Even better is to upload images on the page where you are using them (assuming the same image doesn't need to be populated on several pages). Down the road, I do think we'll be able to solve this by making a module that scans textarea fields for recognized paths (when you save a page) and keeps a list of them in a DB table. When you try to delete something, it'll abort if it finds a link to that asset on another page. While I don't like to have PW getting involved in trying to hunt down and manage links in HTML documents, it's probably worth the compromise. On the other hand, pulling images or files from other pages via the API is a safe bet. If an image gets deleted, it no longer shows up in the API call. So it's quite common to pull the first image on a page for showing a thumbnail with a listing (for example) or pull an image randomly from a page that has several. It's only when dealing with TinyMCE that you may not always want to exercise the power that it gives you in pulling images/files from anywhere (unless you've already made a plan for it).

I think that your simplexml_load_file() is attempting to load from your file system, not from http. So if you wanted to load it that way, you'd probably need to put in an http address, like this: <?php $data = file_get_contents("http://domain.com/sitecontent/"); $xmldata = simplexml_load_string($data); But that's kind of a lot of overhead, to have one http request launching another on the same server. Granted, it happens all the time, but ideally you'd get some caching going here so that you don't have to do an http request and simplexml on every page load. If you can include PW's API, then I think it'd be preferable to avoid the extra http request, like this: <?php include('./sitecontent/index.php'); $home = wire('pages')->get('/'); $home->setOutputFormatting(true); $data = $home->render(); $xmldata = simplexml_load_string($data); Then again, if you can load PW's API, you probably don't need to be dealing with SimpleXML at all. But if you just need to get something going quickly, either of these code examples above should work.

Just posted full documentation on multi-language fields, language-alternate fields, and how to use them. Also includes examples of how to use language fields to create full multi-language websites. Examples include using subdomains, URL post-segments, URL pre-segments, and sessions. I'm interested in your feedback. http://processwire.com/api/multi-language-support/multi-language-fields/'>http://processwire.com/api/multi-language-support/multi-language-fields/ I'm also working on more additions to the new multi language support section of the documentation (http://processwire.com/api/multi-language-support/). Thanks, Ryan

That's not a problem, you can just tell jQuery to only target <a> links that have an href pointing to your site's files. Something like this should work, though could be taken further too. $(document).ready(function() { $("#bodycopy a[href*=site/assets/]:has(img)").fancybox(); });

You are missing out on some good stuff if you haven't used these before. First off, textile and markdown are considered lightweight markup languages. This is the kind of stuff that you want clients to use in places where they might otherwise have to use HTML tags: About LMLs: http://en.wikipedia.org/wiki/Lightweight_markup_language More on Markdown: http://en.wikipedia.org/wiki/Markdown More on Textile: http://en.wikipedia.org/wiki/Textile_%28markup_language%29

I was just about to reply to this and you beat me to it. But I'll continue my original reply anyway– I was going to say that the 'description' field that goes with each image is really intended to be for the 'alt' tag of the image (though not limited to it). But as a result, it's not something that is meant to have markup in it by default. However, if you want to have markup in it there are many ways to go. The way I would probably do it is to use markdown or textile codes in the description, and then run it through that textformatter at output time so that it converts to HTML: <?php $markdown = $modules->get('TextformatterMarkdownExtra'); $description = $page->image->description; $markdown->format($description); echo $description; // outputs HTML