ryan

(Topic moved from Getting Started to Dev Talk) Looks like a good setup! I'm not totally clear about exactly what Homebrew is, but I love the name.

If you need to retrieve a bunch of pages by ID, then getById() is much better than a foreach with get() simply because getById() does its primary work with one query, whereas get() does at least one query per call. But getById is also one of those things that most people will probably never use (it's largely an internal use thing). As a result, it probably just belongs in the 'advanced' API section.

I would really avoid using the h4 title as a URL segment as it seems like a potentially very fragile solution. Page numbers would probably be a little less fragile. If the editor really can't handle repeaters, I'd suggest using <hr> (or something else nice and direct like this) as the page delimiter rather than an <h4>, and sticking to page numbers rather than URL segments.

We have always used ASCII on fields within tables that are for page names (or other names that can't ever contain anything UTF8). Though the tables themselves are always UTF8, even if an individual field within might be defined as ASCII collation. Can you see any potential problems with doing that? Maybe some MySQL version or setting doesn't like this? The "/?/" means the error occurred before PW determined what the current $page was going to be. Everything is UTF8, except for "name" fields. They certainly could be UTF8 too, but figured it would be a better practice and more efficient to enforce ASCII on a field where only ASCII characters allowed. But it sounds like maybe there are issues with doing that I'm not aware of? Though if that were the case, I would also wonder why MySQL would let you change the character set on a field-by-field basis if it wasn't okay to do. This is the first "Illegal mix of collations" error I've heard of in PW.

Thanks Soma, I can reproduce that. I was not using a segment for my default language, so hadn't noticed. It should be fixed on the dev branch.

Big thanks to Mats for the alltpaoland.com example and his clustering updates to my RCDMap class. With these available, I was able to learn enough (and admittedly copy enough!) to make the map project come together: http://www.synbioproject.org/library/inventories/map/ ... my code is a little messy, but it all works for the deadline, and I can go clean it up later. Beyond Google Maps, tools used here are jQuery Mobile, ProcessWire 2.3, ImportPagesCSV module, and ProcessWire Form Builder (for the add/edit map submissions). Thanks again Mats! I don't think I could have made much progress without your alltpaoland site as an example/guide.

No the session should still be active even if they close the browser. Now if they completely quit the browser, that might be different.

It sounds like what you want is instead the MySQL login info? If so, you can put it in a .my.cnf file in your home directory: /home/samuel/.my.cnf [client] user=your_mysql_username pass=your_mysql_password Following that you can access the mysql/mysqldump clients without specifying a username or password. This is helpful for automated backups or [i'm guessing] git based workflow.

Don't worry, I understand. No need to explain, we're all on the same $page. Just trying to make sure I follow up good questions with good answers.

When/where are you guys seeing the 'guest role required' message? Just wondering if this is something that should be fixed in the core ProcessUser module? I guess I haven't noticed this before.

Don't count on the editor though. Make sure you are sanitizing at the server side with HTML Purifier. Rich text editors like TinyMCE and CKEditor don't do any server-side sanitization (they can't, since they are JS apps). So while it may look like they are sanitizing and validating, they can be bypassed easily.

Nice job Soma! Lots of good thinking here, and I like where you are going with the scalability. I look forward to seeing this in the modules directory.

You can go even shorter if you want to <title><?=$page->{'alt_title|title'}?></title>

I'm not sure that I understand exactly what you are trying to do with asmSelect? But it is fairly straightforward to replace the "add new page" process. To do this, copy the existing /wire/modules/Process/ProcessPageAdd/* to /site/modules/ProcessPageAddLuis/. Then rename the class and filenames to ProcessPageAddLuis. Now login to your admin and install the ProcssPageAddLuis module. Then navigate in the tree to Pages > Admin > Page > Add New Page. Edit the "Add New Page" page. Change the "process" field from ProcessPageAdd to ProcessPageAddLuis. Save. Now edit your new module to work how you want it to. It should be safe through upgrades as well.

@adamspruijt it looks like the download link is broken on the http://modules.processwire.com/modules/metro-wire/ listing. Could you update it? Thanks, Ryan

This is what I'd expect to see. This is kind of a mystery, as the language pack shouldn't make any difference here. I'll have to experiment and see what's up. I was going to go take a look at the MetroWire theme, but looks like it's no longer available for download. I'm getting a 404 when clicking the download link: http://modules.processwire.com/modules/metro-wire/

I've added an httpUrl() function to the Pagefile class on my local dev copy, so this should be appearing on the dev branch soon. Ideally there should be a corresponding httpUrl() function anywhere there is a url() function.

Uniques aren't officially supported by that fieldtype, so it's a bit of an unknown. But I would think we should be seeing an exception thrown (and error message at the top of your screen). Do you see anything related in your /site/assets/logs/errors.txt? Can you try switching back to the default admin theme, just in case something about the theme is causing an error to be suppressed.

Looks good Luis! Thanks for making this. One suggestion I would have (for now or a future version) would be to remove the dependency on a field named 'body'. Not everyone has a field named 'body', and others may have one or more other textarea fields they want to use this module with. So you could take an approach of finding all the textarea fields using TinyMCE and make them editable from your addDivs method: foreach($page->template->fieldgroup as $field) { if(!$field->type instanceof FieldtypeTextarea) continue; if($field->inputfieldClass != 'InputfieldTinyMCE') continue; // if you reached this point, this is a field that can be made editable }

Does your name "Hairygit" have anything to do with Git? I figured it did at first, but since you say you don't use Git…

I would say that the blog profile is not the best place to start. It uses more advanced techniques and was designed to be a demonstration of them– These are techniques I don't even use in my own site development, but felt like we needed a profile that would appeal to those looking for a dedicated MVC strategy. The best place to start really is the basic profile that comes with ProcessWire. When you understand that, you really can build anything. If you are wanting to go further, you might like to look at the skyscrapers profile. But the important thing to remember is that there is no "right" way to build your site in PW. This is why even tutorials can be a mixed blessing when you are learning, because they reflect one approach that may not necessary be the right one for you. Beyond the basic profile, you just need to read $page, $pages, PageArray and about Template files. Ignore everything else, because you may never need it. Don't feel like you need to remember or understand everything on those pages. But read through them and make note of what's there. These pages cover 99% of what you will do in ProcessWire from the code side… and probably a lot you won't ever use too. Once you get going and developing stuff, you'll want to keep the Cheatsheet open, which has sections that cover what's on those links above more succinctly. In ProcessWire, you should be comfortable with HTML markup and CSS. But it's less important that you know PHP. You only need to learn a few basics. You really don't need to know any more than you need to know EE tags. Know how to get in and out of PHP from HTML markup. i.e. <?php ... ?> Know what a $variable is – just a place to store a value. Most ProcessWire API functions return a value. Know how to use an if() statement. In PW, you'd use an if() to test if something had a value you wanted to output. Know how to use a foreach(). In PW, you'd use a foreach() to cycle through a page's children, or the results of a $pages->find(...). Know how to output a value, whether: <?php echo $value; ?> or <?=$value?> …both do the same thing. Know how to use include() to include another file, i.e. "<?php include("./header.inc"); ?> I think that covers all you would have to know to do most things from the PHP side in ProcessWire. Can anyone think of anything major I'm missing? Lastly, when you are developing, enable debug mode in /site/config.php: $config->debug = true; This will ensure that you get helpful error messages rather than ambiguous ones.

I actually find it rather difficult to believe that they would go beyond simply disregarding the links (devaluation), and instead make those links actually penalize the site being linked to. It seems like it could be very easy to mistake devaluation for a penalty. Is there any real evidence? If I was showing up first for some term, and then was off the map, I can see how it would look like a penalty. Yet, the math behind it might not involve any penalty at all, just a devaluation of those links from the equation. Wouldn't this be hugely open to abuse? Creating an entire new industry of SEO of hurting competitors by linking to them? After all, it's incredibly easy to create a bad neighborhood of sites, but incredibly hard to create a quality site. I don't claim to have insight on Google, but it seems silly and unsustainable for them to give bad neighborhoods this level of control and manipulation potential. If you guys are right about this and there is testable proof, then my inclination would be to remove ourselves from the picture and simply not have links. The attribution text is ultimately the most important part. People can find ProcessWire on their own. Though this all seems rather silly, as the point of the link is to be a convenience to the user so they don't have to go find it themselves. But I would want to see actual proof before acting upon it. I suppose we could always link it to a Google search for "ProcessWire" too. If some site has a lot of other sites disavowing its links, I can see that as being a penalty factor for the site doing the linking. That would be understandable. I would not have guessed it could go the other way around. I think your proposal is actually very good. It solves all of my concerns. Thank you for the suggestion and idea. Admittedly, I'm now feeling like I need to do more research, but if what you guys are saying is testable and proven, then I'm more inclined to prefer just text attribution rather than a link. We do have a class of modules called Markup modules. This module idea would fit well within that segment.

This is essentially the same thing as clicking a field name while in the template editor. It opens a modal there, but it's the same thing (template-field context).

You probably want to hook the method via something like this in an init() function with an autoload module: $this->addHook('ProcessPageAdd::getAllowedTemplates', $this, 'myHookFunction');

You might also want to check out the Blog profile, which uses views for output (stored in /site/templates/markup/*.php)