ryan

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)

Also to alter the order they display in. One requirement I had for the blog profile is that it should be something that one could get going with and not have to touch code at all (like WordPress in that respect). So the widgets had to be defined in a manner that could be controlled in the admin rather than just the code.

That's right API key isn't necessary with v3. Can you attach the full code? I think there is probably something about the larger context that we're not seeing, and that's most likely where the problem is. But before you do that, enable your Javascript console and see if any error messages are being reported. I am guessing there is a JS error that will answer what the problem is.

Sounds like you already had a page installed called Setup > Languages. Was it for something else? I am guessing there is some other Languages module installed that is preventing installation of the core LanguageSupport module. You may need to uninstall that module before you can install Language Support.

I think this seems like a fine method. There are some users/access modules that you might find helpful, particularly the Page Edit Per User module, that does something very similar to what you are doing. Though your application sounds pretty comprehensive and involved, so you may find any of these modules more as starting points or educational examples rather than complete solutions. Yes. I don't understand the question. But it shouldn't matter where you save the page from. The save() function should always behave the same way. The idea of a "parent page" is purely for structure and doesn't have anything to do with whether a page is viewable. Well, except for access control. If the parent's template defines access and the child's template doesn't, then the child page inherits access from the parent page. I think so, but you are writing about something in-between working directly with an SQL database and working with ProcessWire, so there is some ambiguity there–I don't follow everything you are saying. The API is how you accomplish everything from the code side in ProcessWire. When you know how to put the API to work, you can really automate quite a lot, and accomplish almost anything. What would you use to intercept actions then? GET/POST vars? I don't think there's any problem with using URLs. Avoiding URLs doesn't improve security in any manner I can think of. You'd want access protection either way. Requests that make changes to a database should be POST based, and requests to present information should get GET based (whether using URLs, URL segments or GET variables). ProcessWire includes helpers for doing pagination. Here is more about pagination. Yes. Though most likely you'll call it something other than $page, since $page is the API variable for the currently viewed page. ProcessWire doesn't use a tag-based system, but of course they are very easy to implement for your own use. You might want to look at an existing tag engine like Twig or Smarty. Though if your needs are simple, a preg_match_all() with str_replace() is a reliable way to implement a simple tag engine. However, you may want to evaluate whether a tag engine is really necessary. PHP can do the job faster. So it really comes down to whether writing ":!:first_name:!:" over "<?=$first_name?>" is worth the overhead of a tag engine. One other thing I want to mention overall, is that this sounds like a completely custom application that may potentially be better suited to a full blown framework like Laravel. ProcessWire is both a CMS and a CMF, so it'll certainly do just fine with anything you can throw at it. But I'm questioning whether you need a CMS at all here, as it really sounds like more the territory of a dedicated framework. Personally, I would still build it in ProcessWire because that's what I work in. But you'll find a support system more focused on developing larger custom applications of this sort when working with a dedicated framework. You may still find ProcessWire to be a better fit for what you are doing, but do look at dedicated frameworks just in case.

Actually filename would make a difference here. The template used by the 404 page also includes head.inc. So head.inc gets included twice. If there are any function definitions (that get defined twice) that could trigger an exception. Also if the 404 is getting thrown without some kind of if() statement to know when to throw it, then it would be an infinite loop as the homepage throws it, then the 404 page throws it, and on and on.

Makes sense to me. I will get this in the dev branch soon.

Sounds like a good idea. I'm not sure how to help with this one other than creating the subdomain, but I'll be glad to do that. I do also have a blank processwire.com site profile ready to use (if you want it?), or Nico may be able to provide the German site profile as a starting point.

Nice module Hairygit! Thanks for adding to the modules directory too. Would it be possible for you to update your module with a download link at GitHub? (or to the ZIP in this forum if you don't want to set it up at GitHub).

Debug mode shouldn't make any difference in that respect. Since browsers render output as a big chunk, you don't ever get to see HTML elements rendered individually one-by-one (except for images and ajax). At least not in a situation like this. As a result, if there is a perceptible delay between rendering of adjacent HTML elements, that has something to do with CSS or JS (more likely JS). Whereas if there is a perceptible delay before you see anything rendered in your browser, that can be at the server side or the client side.

What you want to do instead is wipe out what's in the /site/templates/home.php and replace it with your own. The template files included with the default profile as just an example. You don't have to retain anything about them if you don't want to. Though I do recommend using the same name for your home template (home.php) just to keep it simple.

Here you go (I just added this page now): http://processwire.com/api/fieldtypes/images/

Another way to accomplish it is to have the template calling $page->render(); stuff the $originalPage into $page. In this case, /site/templates/main.inc: <div class='widgets'><?php // render widgets $widgets = $page->widgets; if(!$widgets || !count($widgets)) $widgets = $homepage->widgets; foreach($widgets as $widget) { $widget->originalPage = $page; // ADD THIS LINE echo "<div class='widget'>" . $widget->render() . "</div>"; } ?></div> Then in widget-recent-posts.php: $posts = $pages->find("template=post, id!=$page->originalPage, sort=-date, start=0, limit=$limit");

How do you duplicate that? I tried to duplicate but couldn't. Here's the test I ran in my /site/templates/home.php: <?php include("./test.inc"); Here is /site/templates/test.inc: <?php throw new Wire404Exception(); Result was the 404 page.

I think this makes sense. Only issue is the template needs to be aware of that context, rather than just having a $var present like others are. But I think it's probably the right balance.

I understand what you are saying. But the reasons are about consistency, readability, DRY and flexibility. For consistency, we want to have similar/identical hook naming conventions across Pages, Templates and Fields, and was just looking for the right opportunity. For readability, we want people to hook into things that that make sense purely by name. These hooks don't really cost us anything in terms of resources, but reduce potential ambiguity for the developer. I generally prefer more methods to more arguments, if that is an indicator. For DRY, I don't want everyone's save() hook to have to check return values or other things before deciding if it can proceed. I don't want people to have to devise ways of determine if a page was just added or already existed. Basically, I want to offer very convenient "sure things" in terms of hooks, where people don't have to think about internal conditions, and don't have to write code to accommodate them. Lastly, is flexibility for those of us that get deep in module development. I don't want 99% of people to have to think about internal conditions (per DRY above). But at the same time, I want to give the other 1% the flexibility to do so when their need calls for it. For instance a before(save) hook might be more appropriate than a saveReady() hook if I wanted to modify the conditions that will be present. Likewise, an after(save) hook might be more appropriate than a saved() hook if I wanted the ability to take action when something couldn't be saved.

Well I'm glad they do it. But it's not like we don't have a choice. We can put a robots.txt in place to opt-out when/if we want to. Someone searching for ProcessWire, getting something other than ProcessWire, would be considered a poor quality search result. The optimizations that Google makes are intended to increase the quality of search results, not reduce them. However, I recognize that temporary anomalies and unintended consequences can happen, and people occasionally get slapped down when they shouldn't. But that doesn't change the big picture. Google does what they do in order to increase the quality of their search results. If the quality goes down, the audience goes elsewhere, and they know that. Just because you or someone you know got slapped down when they shouldn't have doesn't change the big picture or long term. We should all be working towards increasing quality. Maybe what you are suggesting (changing the terms) does work to increase quality, but by our definition. Looking bigger picture, It does seem grey hat, and I'm guessing Google would frown upon it (though who knows, I could be wrong). But if we proceeded with that understanding, that we are doing this to work around Google's algorithm, then we'd be engaged in a risky behavior. If a future Google algorithm detects our strategy, the sites linking to us would themselves get legitimately slapped down for participating in the risky behavior. Another thing to consider is that your site can't be penalized for who links to you, or in what quantity. Only those linking to you, and the value of the links [to you] can be penalized. If a thousand sites out there have a link in the footer that says "Powered by ProcessWire open source CMS", does that mean that ProcessWire deserves a high placement for the term "open source CMS"? No. It seems reasonable to me that a large quantity of links like this (whether identical or randomized) should not carry the same value of more organically generated links. If I start randomizing the anchor text of those links, then I'm trying to make that link look like something it's not in order to boost the value of it. When we ask for attribution links, Google is not the audience. Google can do what they want. If they give us a boost, great. But we want attribution links so that people can show pride in what they run and share it with their audience. Old fashioned marketing. Regardless of whether Google considers the value of those links reduced, due to quantity and similarity, we benefit. There is no situation under which the presence of those links could hurt us more than if they weren't there in the first place. Maybe this is totally okay. But it seems like a grey area to me. If it has the blessing of someone like Matt Cutts, then I'd be supportive of it. Otherwise, I'd worry about involving users of the module in a potentially risky behavior. I may be able to write a module to outsmart Google in the short term, but not long term. While one may not equal the other, they also aren't isolated from each other. Yes. But note that there is no "bottom-line" (this is not a for-profit venture), and I do not see Google as our primary source of future growth. I see primarily word-of-mouth, but also the resulting links and social networks as being our source of growth. But even for my for-profit clients, I advise them to do the same and focus on the site and audience (and accessibility to them) rather than Google or some other search engine. Of course we care about Google, and pay attention to the webmaster guidelines, especially search accessibility and semantics. But I don't get involved in sites or business models that are built around living or dying based on organic search placement. That's a risky model regardless of what you do. Damage only relative to the potential value of those links if all links were equal. And I don't believe attribution links should carry the same value as organic links. Maybe they don't deserve more value than a rel="nofollow", I really don't know. Thanks. I also appreciate your interest in helping our search performance. I'm not trying to challenge anything you say, just enjoy participating in conversations about this stuff, and hope you do too. While I'm very grey area about what you are proposing (and I may be wrong), I do think we have plenty of room for improvement from the SEO side, and discussion like this is a great launching point.

I don't think the delay would be coming from ProcessWire. Most likely client side, styles or javascript. Try removing these and working forwards from there till isolating what it is. Sometimes browsers get in an odd state too, so the first thing to try might just be quitting and reopening your browser. But if that's not it, definitely remove CSS and JS from the equation, and then start adding them back till you isolate it.

You can make any page a settings page. Some of us use the homepage for convenience (since it is the root owner of the pages below it). But you could make your own custom 'settings' template and contain them all there instead if you preferred. I'd also suggest deciding which settings need to be dynamic and which don't. Something like 'site title' may not need to be dynamic. I prefer to store this stuff in $config or with PHP define('key', 'value') calls, either of which you could put in /site/config.php.

You can only pass static strings to the __() function. At least, the translation parser will only be able to find static strings. The only reason you'd put a variable in a call to the __() function, is if you knew the text was already available translated, and wanted to retrieve the translated version. But that text would have had to appear statically, somewhere else in the file. To make a multi-langage image field, you can use a Repeater. Your repeater would contain two fields: 'image' and 'summary'. Make the 'image' field of type Image, and set to to contain max 1 image. Make the 'summary' field of type TextLanguage (or TextareaLanguage). The Image field is the next one on the list to make multi-language capable, so should be within the next major version of ProcessWire.

Thanks Maniqui, this is great info! You are officially our Git advisor, should you choose to accept the job. Actually those 3 lines aren't supposed to be in dev OR master. It appears to be just a duplicate if() statement to the one right below it. It doesn't appear to be a problem, but of course it's unnecessary redundant code. So I will have to remove this from master. I actually have no idea why or how there are duplicate lines there. But thank you for finding it. Great links too, bookmarked and look forward to reading.

Very nice! But it took a long time to load here. Not sure if that's because of the connection that IP is going through, or if it's the result of loading and rendering data for 533 pages (?) in one request. But if you are loading that many pages in one request, it's good to keep in mind that you can only scale so far using that method. Eventually, you'll fill up memory if that table keeps growing. If it's not going to keep growing, then you may want to at least cache it with MarkupCache. Usually if I'm rendering something that's reusable and has 50+ pages loading as a result, I use MarkupCache to cache the output.

Double check that you don't need a more specific URL for this. I'm guessing you might need it to be "/sendEmail.php" instead? I would guess those values have to be escaped if you bundle them in a string like that. To make it simpler, I would suggest changing this to: data: { name: name, email: email, subject: subject, comments: comments }

For front-end use, I would just follow any instructions that come with CKEditor itself. ProcessWire really tries to give you an environment on the front-end where you can implement anything without having to worry about the system itself. The only reason I would use InputfieldCKEditor on the front-end is if you are already using other Inputfields and including their scripts, css, etc. Otherwise, better to just use CKEditor and implement the same way they do on their website.