• Content count

  • Joined

  • Last visited

Community Reputation

18 Good

About johnstephens

  • Rank
    Jr. Member

Recent Profile Visitors

2,040 profile views
  1. @cobrown Wouldn't that include all architecture that uses right angles?

  2. Thank you, ottogal and Zeka! The Autocomplete field + allowing page creation is exactly what I needed. Perfect!
  3. Hey, Intelligentsia! I have an unusual data modeling need, and I'm not sure how to approach it. I'm creating a ProcessWire template to track Events (after the fact). When creating an event, the user will be able to select a category (Page reference field), start and end times (datepickers), etc. One datum we need to track is the number of participants. - Some participants may have been enrolled previously, so I could have a multi-select page reference field linking to the individual participants. - But some of the participants will not be enrolled, so I'm thinking I need a numeric entry for those who are not enrolled. When I report on participant counts for each event, it would be fine to add the number of registered participants to the numeric entry of unregistered participants to form a total. But when I report on participant counts for a series of events, that won't work. Suppose Event 1 has 25 participants, and event 2 has 26 participants (one participant is new, and the other 25 attended the first event). I create a report that counts participants for both events. I want the report to show 26 participants total—not 51. I'm not sure how to model this. If *every* participant was registered in some way, we could just log unique persons via a mult-select page reference field. But creating a unique identifier for every participant—especially for participants who attend only one event—would be an overwhelming burden for the client. On the other hand, plain numeric entries seem wholly inadequate. I'm not sure how to normalize or finesse the data model to get the information I need without creating an unmanageable data entry chore. Any ideas?
  4. This is a story of desire, stilted romance, triumph, and discovery of a simpler way. TL;DR: ProcessWire has hidden goodies in it, but it makes me wonder what else I'm missing. The other day I was thinking, "Hey, I make a lot of navigation. Lists of links, glossary-style HTML sitemaps with links and descriptions, nested menus, etc. I wonder if I could automate some of the markup and stuff by making a custom function?" So normally, I might build a navigation menu in ProcessWire like this: $menu = $pages->get('/')->children; $out = "<ul class='my-menu-class'>"; foreach($menu as $item) { $out .= "<li class='my-item-class'><a class='my-link-class' href='{$item->url}'>{$item->title}</a></li>"; } $out .= "</ul>"; Within this, there are only a handful of things I might want to handle differently for different menus: The classes, the HTML elements, the pages included, the sort, and the limit, for a few. After some amateur writing and testing, I came up with a new object class that would take some config and return a menu in HTML: $out = ''; require_once('./ClassMenu.php'); $menu_settings = array( 'pages' => $pages->get('/')->children, 'label_class' => 'my-label-class', 'label_tag' => 'dt', 'desc_class' => 'my-description-class', 'desc_tag' => 'dd', 'desc_field' => 'description', 'wrap_class' => 'my-list-class', 'wrap_tag' => 'dl' ); $menuzilla = new Menu($menu_settings); $out .= $menuzilla->render(); The above menu would return something like this: <dl class='my-list-class'> <dt class='my-label-class'><a href='/about/'>About</a></dt> <dd class='my-description-class'>About page description…</dd> <dt class='my-label-class'><a href='/products/'>Products</a></dt> <dd class='my-description-class'>Product page description…</dd> <dt class='my-label-class'><a href='/misc/'>Miscellanium</a></dt> <dd class='my-description-class'>Miscellanium page description…</dd> <!-- etc. --> </dl> It worked great, and it was pretty flexible. As I considered adding more complex functionality, I remembered Soma's tutorial about building forms with ProcessWire, and I wondered if I could learn something about building markup from ProcessWire's render method. That's when I found MarkupPageArray. MarkupPageArray, for those who don't know, adds a render method to page arrays, giving them the ability to generate HTML without further ado, like so: $out = ''; $menu = $pages->get('/')->children; $out .= $menu->render(); But what if you don't like ProcessWire's default markup or classes? You can override that simply: $out = ''; $menu = $pages->get('/')->children; $out .= $menu->render(array( 'listMarkup' => "<dl class='my-list-class'>{out}</dl>", 'itemMarkup' => "<dt class='my-label-class'><a href='{url}'>{title}</a></dt><dd class='my-description-class'>{description}</dd>" )); This renders the same HTML I posted above, using only ProcessWire's own API and no custom functions. It brings a tear to the eye. So my question is this: What other common site components are hidden in the API waiting to be uncovered by the hapless and meek in their thrashing about for wisdom?
  5. Concepts like "bootstrap script" and writing my own importer were a bit much for me when I initially posted this question, but now that I'm facing a real need I might have to wrap my mind around them. At the time I wrote, I didn't have a specific site in mind to convert, but now I do. It's one of my more complex Textpattern sites, but it's not insane. Here's what I have: - 7 major content "sections", some of which would be nested in a ProcessWire site. I also have some utility sections used for things like search and site map. - 660 "articles", most of which belong to a knowledge base. - 39 categories in two major divisions. Each article in the knowledge base belongs to two categories. - The site uses Textpattern's MLP plugin/hack to offer content in two languages. The 660 article IDs include the renditions in both languages. On the front end, that means you can click on a language link for any article and view it's rendition in the other language. The URL changes from domain.tld/en/{section}/{url-title} domain.tld/es/{section}/{url-title}. - The site uses 15 custom fields, with the glz_custom_fields plugin offering support for different field types. Articles in different sections use different combinations of the custom fields, but all the custom field data lives in the same table with the articles. I think that covers all the complicating factors. In a vanilla Textpattern installation, all the article content lives in one table, and I suppose importing it would involve some way of mapping the columns of that table to pages and fields in ProcessWire, with the "section" field designating the rootParent page. But this site has the added convolution of a localization table that maps articles in both languages so they can be linked appropriately. Tom, when you say you transferred the content manually, do you mean you opened the article in Textpattern's editor (the Write tab) and simply copied and pasted each field to ProcessWire? Is that the method you'd recommend for this site, or is there some way of automating it that you'd suggest? Thanks in advance for any guidance you can offer!
  6. The thing I love about my Ghost blogs is the writing UI: Write Markdown on the left, and it appears fully rendered on the right. It also has the coolest while-you-write image upload utility I've ever seen. That's not covered by pw-ghost, right? Not having Ghost's writing UI isn't a deal-breaker, and I can't wait to try this out. If I could replace my Ghost blogs with a ProcessWire equivalent, I'd love to forgo the chore of maintaining a Node server!

  8. @sketchapp Updated to v39, and I can't paste text into text boxes anymore. Where can I download Sketch 3.8.3?

  9. Did he smile his work to see? Did he who made the Lamb make thee?

  10. @kevinrollins Later iterations of the character turned it into tales of the flexing macho jock, which became its own genre.

  11. RT @chuckfager: Friends, Orlando's not only a city in Florida. A Quaker prophet saw it coming in 1994:…

  12. Interfaith peacebuilding in Harrisonburg:

  13. RT @theintercept: More than 90 percent of 18- to 24-year-olds in Iraq consider the United States to be an enemy of their country. https://t…

  14. Thank you, Sérgio! I installed and tooled around with ProcessMigrator, and I don't think it does what I had in mind. To clarify, I was wondering if there was a way—whether natively, or by module—to save the template and field settings to a text file (JSON would be perfect) somewhere in the /site directory. ProcessWire would then use that config file instead of the Templates and Fields panels. So instead of configuring Templates and Fields in ProcessWire's UI, these settings would be entirely configured in a text file, that could be kept with the template PHP files in version control. Does that make sense? Based on my quick look at ProcessMigrator, it lets you save your Templates and Fields settings (and a lot more) to the file system, but it doesn't read that data back into ProcessWire unless you trigger an Import using the Migrator panel. Is that right?