Leaderboard

hi all, online since today, a new site for a big doctor's practice specialized in prenatal diagnosis: praenatalmedizin-koeln.de the site replaces an old outdated site and i put special effort to maintain the very good serp ranking of the old site. that's why there is an exhaustive faq page, an additional glossary page, and the tagline on top of each page. the calendar of recommended examinations (see bottom of page /untersuchungen) was done with the page field type. the editor may allocate any page from the /untersuchungen section to the calendar with the help of page field type. once allocated, the page qualifies for the calendar if there is an entry in the respective field SSW (saying for which week the examination is recommended). if this field is filled, the information is automatically added to the calendar and sorted. if no "ssw" is given, the page doesn't show up in the table. your comments are welcome. please let me know if you find any bugs. modules: redirects, email obfuscator, after save actions

Greetings Everyone, I just completed building a site which serves as a companion to a book published by Rutgers University Press. The book is about Holocaust films. The author uncovered these films during extensive research in Russia, Israel, and elsewhere. This site is designed to be used as a college classroom resource. Teachers will go to the site, play movie clips for their class, then use the chapter summaries and discussion questions as further materials. For the video pages, I used the video.js player. Every movie page includes an .mp4 and a .webm file, in order to cover as many browsers (and tablets) as possible. The movies play in regular and full screen. Although the site is launched, I am still planning to build additional sections for "educator resources." I may also make some style changes in the coming weeks. Using ProcessWire made the building of this site very smooth! The author can easily log into the site, add or edit chapter text and discussion questions, and upload video files. She can also easily edit any of the static pages. This is a relatively simple site that will get a lot of practical use in college classrooms. Here it is: www.phantomholocaust.org Thank you, Matthew

hmmm, beat me, but i'm not too unhappy with pw not becoming much to much popular ... wp is popular, because it's a jap-cms (just-another-plugin-cms). wouldn't like to see pw go this route ... but, however, presumably popularity helps ryan to make a living from his amazing work. and that's desirable by itself.

@Ovi, Excuse my ignorance. I am not sure I get why you need to hook into any method? If a comment is submitted, it is saved to the db (directly if it does not require approval and later if it does require approval by Admin). In that case, why not just count the comments in the db directly? Since comments are related to their pages, you will know how many comments there are per page(?) I'm probably not getting it (I usually don't many times, hehe) and you are far way a better coder than I am, so would request your indulgence to unravel this for me please Edit: Useful? http://processwire.com/talk/topic/1205-comment-counting-returns-odd-number/ OR: Just use PW API in your template file: In my tests, this code sorts my posts (pages) in a list according to number of comments (and echoes the number of comments per post). Since there is a page refresh after each comment submission, the sorting is always up to date... foreach ($pages->find("template=post, sort=-comments.count") as $reviews ){ echo "<li>{$reviews->title} - " . count($reviews->comments) . "</li>"; } Other topics: http://processwire.com/talk/topic/594-how-can-i-use-pagination-with-comments/ http://processwire.com/talk/topic/357-creating-comments-via-api/ http://processwire.com/talk/topic/1930-comments-question/ http://processwire.com/talk/topic/1624-comments-module-multi-pages-display/

new article in Noupe: http://www.noupe.com/cms/processwire-cms-with-a-difference-77309.html

Greetings, I would be happy to make this into a site profile if anyone is interested. Thanks, Matthew

[[gallery tag=skyscrapers" sort="-created" limit="10" paginate="true]]

If you decided to do it in Admin and do not wish to create a module, you can use Diogo's ACP module. See http://mods.pw/4Y and http://processwire.com/talk/topic/3474-admin-custom-pages-module/

Well I lost the parrot sometime around when I was last being a pirate: But I found him again when I went to a fancy dress party as French Polynesia (the theme was countries): What? How is that French Polynesia? French (beret) polly (parrot) knees (I'm showing mine) ear (Spock ear). French-poly-knees-ear. No, nobody guessed it on the day

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice. Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4.

I first asked this question on Twitter but I guess the forum is a better place to get a good answer. The following code is taken from the head.inc file of the default PW theme: // Create the top navigation list by listing the children of the homepage. // If the section we are in is the current (identified by $page->rootParent) // then note it with <a class='on'> so we can style it differently in our CSS. // In this case we also want the homepage to be part of our top navigation, // so we prepend it to the pages we cycle through: $homepage = $pages->get("/"); $children = $homepage->children; $children->prepend($homepage); foreach($children as $child) { $class = $child === $page->rootParent ? " class='on'" : ''; echo "<li><a$class href='{$child->url}'>{$child->title}</a></li>"; } The definition of $page->rootParent from the cheatsheet: I understand, that if you have the following page structure … Home About ProjectsProject ASubproject 1 Project B … and calling $page->rootParent->title on »Subproject 1« outputs »Projects«. But why can I also check with it that a page is the »current« one like written in the above code ($child === $page->rootParent)? I guess the problem I have with this is that one method implies two different semantics (which confuses me). Just wanted to share my thoughts about this as I’m trying to truly »learn« PW form the inside out.

It depends on your needs. I am no coder myself; I could probably do a simple module that says hello world! and that's it . A module is good in that it can be shared and reused easily on multiple sites. Just click and install and you are off. But, in some cases, you just need something custom using something familiar to $page API....so you use ACP. Of course you can share (if you wanted to) the code in your ACP (child) template file if others want something similar or if you want to reuse it on some other site. No need to make a module if you can't, at the moment....we will get there eventually, I believe.

Horst, Actually, from what I can tell from the Blog Profile, they are not PW Pages. They are stored in the field (table) "field_comments" (see screenshot). They are associated with their posts (pages) though. I'm sure there is a way to "hook" into them though...

Yes, in PW 2.3, you need to create the child page. Both pages (parent ["shows"] and child) will be in the site Tree. The parent will also be listed in the Admin menu (next to Settings, Modules, etc. - depending on the Admin theme you are using.). Clicking on it will open your custom admin page. In the dev version of PW you don't have to create a child page. See Diogo's github for more info. What the module does is render the child page using that child's template. I find ACP really handy. All PW variables are at your disposal and the page is safely hidden in Admin . Seen the crazy things I've been doing with it ?

*Missing id added "bcwrapper" and adjusted the padding in #main and placed the breadcrumb at the top. Pull Request

Hi Vineet - I read up a bit on the XML datafeed that FoxyCart provides, and that feed is what is read/parsed to decrement the inventory in something like the ModX plugin that is related to FoxyCart inventory; you should be able to easily hire someone to adapt that for processwire, and then you would be able to automatically remove sold seats http://modx.com/extras/package/foxycartinventory i guess the main snafu, again, is how to you prevent 2 users from both purchasing the same seats? You might have to use session variables, for example maybe when someone adds seats to their shopping cart, the page redirects to a processwire template that can run a script that would place the seats in that person's cart on 'hold' (and prevent them from being added to another users cart), so you would have to have 3 status types for each seat, SOLD, AVAILABLE and HOLD; then after the person checks out, your XML datafeed parser would check the sold seats against the ones on hold and then change their status to SOLD; you would also have to have it so that the cart expires in some short time frame, otherwise what happens if someone adds seats to their cart, but never checks out - i'm not sure what the default cart expiration is for FoxyCart. The bad news about OvationTix is that it is a complete system, and already does all of the things you have spent your time making, like it has it's own seating charts, seat selector, and backend management of shows, showtimes, etc.. So i don't think you would really want to use it, unless you need something full featured and needed it really fast; With Ovation, one of the other issues is that you can't for example make your own seating chart – the OT admins have to make that for you... (i think you explain to them the seating layout of the space and they configure that from their end..) My recommendation would be to see what you're clients budget is for the shopping cart component and the payment processing, and if they can afford it, then go with Foxycart; maybe search the FC forum for info on unique items and how to prevent multiple users purchasing, as well as if anyone else has done theater or ticketing.. Edit: i gave this more thought, and came up with the idea of keeping the add to cart and all of the logic for your site within processwire, for example using apesia's shopping cart module. Then you could control more elements and style to the cart and any also execute any custom processing you would need within processwire; all you would have to do is to make some changes to the module to let the last step bring the user to the foxycart checkout. For example you could wrap the whole cart view in a form element and use the foxycart tags to achieve adding all of the products from the 'processwire cart' to the 'foxycart cart' and redirect to the checkout; Foxycart makes it easy to add multiple items to the cart at once.. <form action="http://YOURDOMAIN.foxycart.com/cart" class="foxycart" method="post"> <input type="hidden" name="name" value="Les Miserables" /> <input type="hidden" name="theater" value="Imperial Theater" /> <input type="hidden" name="datetime" value="06-05-2013 8:00PM" /> <input type="hidden" name="seatNo" value="Q13" /> <input type="hidden" name="2:name" value="Les Miserables" /> <input type="hidden" name="2:theater" value="Imperial Theater" /> <input type="hidden" name="2:datetime" value="06-05-2013 8:00PM" /> <input type="hidden" name="2:seatNo" value="Q14" /> <input type="hidden" name="cart" value="checkout" /> <input type="submit" value="Checkout" /> </form>

As usual Italy is at the bottom of the list....we are too proud of pizza and Cristoforo Colombo to make a step towards evolution

This is great! Thinking loud here: If you add tags to images, (lets say: cars, beaches or skyscrapers) then you could easily create albums. [[gallery tag=skyscrapers]]

Just want to add that another benefit of taking the JS approach is that the pages could still be cached by PW's template cache or ProCache, etc.

Here's a proof of concept PW Admin Theme Switcher (video and write-up). It shows how versatile PW is. Since everything in the PW tree is a page, including Admin this was easy to do. I think on the roadmap PW will eventually allow switching between Admin Themes? Anyway, here's how I did it (verbosity below is intentional ). This is not a module but can easily be converted into one. Currently, I don't plan to do so since I suspect it will be overtaken by events (roadmap). Instead, I used the excellent Admin Custom Pages (ACP) module. On load, PW will first check if there is an admin template at /site/templates-admin. If there is none, it will check in /wire/templates-admin/. The file it looks for first is /site/templates-admin/default.php 1. I copied the contents of /wire/templates-admin/ to /site-templates-admin/ 2. I modified the contents of default.php as shown below in order to use it as a controller file $theme = $pages->get(1424)->theme_selector;//id of admin theme switcher page (the child page) include($config->paths->adminTemplates . "{$theme->name}/default.php"); 3. In order to use ACP in PW 2.3, you have to create a parent and child page. The child page will be rendered in the Admin. 4. I created pages under Admin as follows: Admin Theme Switcher Admin Themes (id#1424) Default Teflon Moderna, etc. 5. Admin Theme Switcher has nothing of interest. It just enables me to render its child page in PW Admin. Admin Themes has a single Page Reference Field from which only its children can be selected. This field is called theme_selector. Its reference value is the ID of whatever child page of Admin Themes is selected. 6. Default, Teflon, etc., have various fields to hold data about the themes - author, version, description, screenshot, etc. I populated these as needed. 7. In the above code (#3), 2nd line, I am telling PW where the default.php is. I am appending the name of the selected child page of Admin Themes. Hence, if the current selected page is Minimalist Blue, its PW name, minimalist-blue is included as part of the path. This means I need to create a corresponding folder at that path. 8. I grabbed all my themes in their respective folders including all their files and copied them to /site/templates-admin/. This ensured that there would be no conflict having multiple themes in /site/templates-admin/ folder. I also copied the default PW theme with all its files into a folder called default. I ended up with a structure like this: /site/templates-admin/default/ /site/templates-admin/teflon/ /site/templates-admin/moderna/ /site/templates-admin/appy/ etc. 9. Of course since the themes were now in sub-folders, paths in their respective default.php would be wrong. I needed to change this, e.g. in /sites/templates-admin/teflon/default.php, I changed the paths as follows: $config->styles->append($config->urls->adminTemplates . "teflon/styles/ui.css?v=2"); $config->scripts->append($config->urls->adminTemplates . "teflon/scripts/inputfields.js"); $config->scripts->append($config->urls->adminTemplates . "teflon/scripts/main.js?v=2"); $config->styles->append($config->urls->adminTemplates . "teflon/styles/droppy.css") <?php include($config->paths->adminTemplates . "teflon/topnav.inc"); ?> 10. Now that all is set up, there's two ways to change the current Admin theme: a. The template file of Admin Themes has a foreach that loops through its child pages (the theme pages) and outputs the meta data in a I column Grid. Each item has a radio input field to select the theme. On save, jQuery Ajax sends the single value (ID of selected theme) to a simple processor file. The processor file updates the value of the single Page Reference Field (theme_selector) using PW API. Via JSON, the processor then tells jQuery if update was successful and page is reloaded. b. Alternatively, the theme can be changed by editing the Admin Themes page, selecting a child page (theme) using the single Page Reference Field (theme_selector) and saving. PW will auto-reload the page, applying the new theme. As you can see, there is no rocket science here.....just an amazing CMS

I build this yesterday and Ovi sponsored it for open source. Little tweaks and testing before release.

removeAll() is a method of a PageArray not a Page. So I think your code will need to check what type it's dealing with in order to avoid that error. if($reset) { if($page->$name instanceof PageArray) $page->$name->removeAll(); else $page->$name = null; }

@diogo - this is working great.... in 20 minutes i made a product listing page for a client that displays a sortable, filterable table of all of their products, so they can find things without using the page tree... -marc

From this page on php.net: So for objects === has got to be faster because it only has to compare one thing (memory location). Whereas, == compares lots of things. So I think that === is what you want when comparing two pages to see if they are the same. Most of the time this works perfectly. But there are some situations where that could fail. An example would be if you loaded a page $a, saved page $b, then loaded another copy of page $a, which we will call $c. If you compared $a === $c, it would fail because you'd saved $b. Why? Any time you save a page it clears the memory cache. So while this seems like an unlikely situation, it can happen. As a result, it's technically more reliable to compare pages by their ID property, like: $a->id == $c->id would still work in situations when "$a === $c" wouldn't. You can also do "$a" == "$c", which is the same as comparing the id property. This works in ProcessWire since the string value of any page is its ID.