ryan

I think this is one of those things that philosophically we don't think belongs in the CMS. You are better off using a service (MailChimp, etc.). Doing large email distributions from your CMS/webserver there is always a danger of your server ending up on an email blacklist. Though I can't argue with the convenience factor (I'm guilty of sending out my small distribution newsletters directly from the server). But if I built this to work right in the CMS, I'd probably feel like I was encouraging some bad practices. Now I've heard of others working on things like MailChimp integration with ProcessWire, and that actually sounds pretty interesting.

The site profile exporter was originally designed to serve as an upgrade tool from PW 2.0 to 2.1, which had some fairly major changes. I will have to update it for multi-language support here soon. But admittedly I don't use it very often myself just because it's easier to save the database to an SQL file and copy all the site files, than it is to use the profile exporter. The profile exporter is more useful for creating a reusable profile to share with others in the modules directory. This is one of the reasons why it doesn't include user accounts in the profile. When it comes to migrating a site from one server to another, it's better to just copy the files and database.

The line number for MarkupSitemapXML is cut-off in the error message you pasted, but that line number would reveal the call that is triggering it. Another alternative is to use a template file. I posted an example here: http://processwire.com/talk/topic/3846-how-do-i-create-a-sitemapxml/

I'm wondering if YSlow/Chrome might be incorrect in this case. WillyC's htaccess looks right to me. You might need to clear your Chrome cache and restart it.

I understood the slash issue. But for the rest of it, I still don't have a full picture of the issue here or how to duplicate it locally. Does the method referred to here in the "or this" part not work? When you say the localUrl() breaks the menu, what do you mean specifically– still the "localUrl does not exist" error message?

It's not a private property. You can set it via $rss->css = '...'; This property can also be set from the module configuration screen. I think the problem here is that it looks like you guys are setting it without an http host. $config->urls properties don't have host names in them, and an RSS feed would probably need a host name in it. I'm thinking this would work? $rss->css = 'http://' . $config->httpHost . $config->urls->templates . 'styles/rss.css';

To create a sitemap.xml you can use Pete's Sitemap XML module, or you can create a template file and page to do it for you. This post explains how to create a template to do it for you. The benefit here is that you may find it simpler to tweak a template file than a module, though either is a good solution. Here is how to do it with a template file and a page: sitemap-xml.php <?php namespace ProcessWire; /** * ProcessWire Template to power a sitemap.xml * * 1. Copy this file to /site/templates/sitemap-xml.php * 2. Add the new template from the admin. * Under the "URLs" section, set it to NOT use trailing slashes. * 3. Create a new page at the root level, use your sitemap-xml template * and name the page "sitemap.xml". * * Note: hidden pages (and their children) are excluded from the sitemap. * If you have hidden pages that you want to be included, you can do so * by specifying the ID or path to them in an array sent to the * renderSiteMapXML() method at the bottom of this file. For instance: * * echo renderSiteMapXML(array('/hidden/page/', '/another/hidden/page/')); * */ function renderSitemapPage(Page $page) { return "\n<url>" . "\n\t<loc>" . $page->httpUrl . "</loc>" . "\n\t<lastmod>" . date("Y-m-d", $page->modified) . "</lastmod>" . "\n</url>"; } function renderSitemapChildren(Page $page) { $out = ''; $newParents = new PageArray(); $children = $page->children; foreach($children as $child) { $out .= renderSitemapPage($child); if($child->numChildren) $newParents->add($child); else wire('pages')->uncache($child); } foreach($newParents as $newParent) { $out .= renderSitemapChildren($newParent); wire('pages')->uncache($newParent); } return $out; } function renderSitemapXML(array $paths = array()) { $out = '<?xml version="1.0" encoding="UTF-8"?>' . "\n" . '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">'; array_unshift($paths, '/'); // prepend homepage foreach($paths as $path) { $page = wire('pages')->get($path); if(!$page->id) continue; $out .= renderSitemapPage($page); if($page->numChildren) $out .= renderSitemapChildren($page); } $out .= "\n</urlset>"; return $out; } header("Content-Type: text/xml"); echo renderSitemapXML(); // If you want to include other hidden pages: // echo renderSitemapXML(array('/path/to/hidden/page/'));

This is what the system status for fields, templates and pages are designed for. For instance, the Language Support modules create system fields, templates and pages to ensure they can't be deleted. System fields can't easily be deleted even at the API level. It's intentionally difficult, requiring you to set it to an override value before it'll remove them. As a result, simply uninstalling a module will not cause system fields to be deleted, unless the module is specifically deleting them in it's uninstall() method. Since we're talking about fields here, here's how to make a field a system field: $field->flags = Field::flagSystem | Field::flagPermanent; flagSystem means that the field can't be deleted or have it's name changed. flagPermanent means that the field can't be removed from any templates where it is assigned. They can be combined like above (which is usually the case), or used individually. It's not possible to delete system fields from the admin, but it is from the API. If you need to delete a system field at the API level, you have to assign an override flag to it first, otherwise it'll throw an exception when you try to set a non-system status to it (which prevents the deletion). This is a form of "are you sure?" from the API side. $field->flags = Field::flagSystemOverride; $field->flags = 0; After that, a field that had a system/permanent status can be deleted.

Assuming I understand Redbean correctly (I haven't investigated too much), it looks like it's providing data storage/retrieval capabilities, which is something ProcessWire already does for you. I'm not sure that I understand what the purpose if integrating the two would be. But I think the best practice would be to use ProcessWire for storing the data instead. Still, if you want to integrate the two, give it a shot and let us know how it goes. You should be able to test things out just by pulling in Redbean from your template file.

Now there's a new idea for a module. I think that regardless of what system you build this in, you'll have a lot of custom work to do just because the needs are quite specific. While this could all be done without add-ons in ProcessWire, it would simply mean that you are coding many capabilities yourself. If you enjoy using ProcessWire, you'd probably love building it. But if someone has already written add-ons for another platform that do exactly what you need, you'd just have to balance that with the cost of your time. By that token, $970 doesn't seem like much. There's no doubt you could build all of this in PW and have a blast doing it, but if you've not used ProcessWire before I'd recommend starting with a smaller project to learn the ropes first.

The "%=" was working for me when I tested it locally before the last reply. And that does translate to a LIKE query. The internal server error means you'd need to turn on debug mode or examine your /site/assets/logs/errors.txt to see what the error was. But what was the full selector? I'm just curious if maybe the value needed to be quoted or something like that. Either way, glad you found a way to get it working.

Since you are dealing with the contents of a Page reference field, already loaded in memory (it sounds like?), take a look at the WireArray section of the cheatsheet, which outlines several methods you can use. Be sure to show the "advanced" options in the cheatsheet, because there is a lot in there. Take a stab at it and post what you've got. From there, I think we'll have a better idea of what you are trying to do, as well as a solution, if you can't get it working.

ProCache doesn't yet support multi-domain/multi-site, but this is definitely on the roadmap.

This module is now updated to use the new Twitter API: https://github.com/ryancramerdesign/MarkupTwitterFeed Be sure to read the install/upgrade instructions. Also note that the module now requires PHP 5.3.

Thanks, I understand now. I have corrected the issue so that now it should redirect to the slashed version when accessed without a slash (dev branch 2.3.1)

Thanks Soma, I confirmed the issue, at least in 2.3.1 and fixed it yesterday. I'm not exactly sure when it was introduced, but it's possible it's been there for a couple of major versions. The entries were getting deleted as they should, but then inserted again when the $page->save(); occurred within the same function. The thing that I'm not yet sure about is why i had a $page->save(); in there, which doesn't seem necessary. But there must have been a reason for it, which escapes me so far. So I've left it there commented out to examine further.

Have you seen any interactive TinyMCE configurations anywhere? I'd be interested in checking them out for ideas. It seems to me that TinyMCE's configuration options are such that it's not worth trying to build an interface to it. Such an interface would be overwhelming to both user and developer. I actually kind of like having a passthrough giving fields to cover the major configuration components, like we've got. It means TinyMCE's docs and support are still applicable, rather than us being responsible for every single possible option and supporting all them ourselves. But I also like the idea of pointing it to a custom JS file, for the reasons you mentioned. Though as an option, because I think it'd probably be overkill for many (including me) that usually only add an extra button for <hr> or something like that. But I'll plan to add this option.

'email' isn't in a fulltext index like 'data' is. So the fulltext index operators *= and ~= aren't going to work there. But if searching out a full email address, you are doing an exact match and would just want to use "=", i.e. $search = $pages->find("comments.email='me@tomrenodesign.com', sort=-created"); Or for a partial match, use the LIKE operator: $search = $pages->find("comments.email%='tomrenodesign', sort=-created"); I haven't tried it, but I think that should work.

Not sure I get it. What are the situations where it redirects to a URL without a slash?

And I've started to do it (the section for WireArray is now updated). The system Soma put together here is fantastic. Yes it can. Though I think $pages->add() is mainly useful without going to far on the fields there. I still find the regular syntax (populating the field values directly to the $page object) the most readable. I'm a little confused, as there aren't any parallels between MODX and ProcessWire in this regard. Though if ProcessWire were to stop evolving, then maybe that would be a parallel with Evo? (though glad to hear others are working on continuing Evo). No plans to stop evolving here. Switching to PDO, then namespaces and composer support is part of that evolution. This evolution is important for ProcessWire to grow and ensuring it remains the best tool for the job. All ProcessWire upgrades are optional of course. You don't have to upgrade unless you want to. I'm still running Photoshop CS3. ProcessWire is a big enough software that some changes will be more valuable to some than others, depending on what you are doing with it. As ProcessWire evolves, sometimes modules that want to support it will also have to evolve. As for now, FormBuilder is the only module I'm currently aware of that had to be updated in order to keep working with this version. That's not really a surprise, as FormBuilder is probably the most complex PW module out there. There may be more, but none that I've come across yet. What I'm much more shy about is doing anything that would require changes to one's site templates. I see API syntax as locked for changes, but not additions. We would version the API if any major syntax changes were ever necessary. So upgrading from one version of PW to another should rarely if ever require changes to your own site templates, unless your site templates are doing some very low level stuff. As for server, PHP 5.2 was EOL'd by the PHP team more than 3 years ago. They are no longer updating it. Meaning, none of us should still be using it, at least not for current projects we are maintaining or keeping up-to-date. Trying to maintain PHP 5.2 compatibility through future versions would be a drag on the project and people's usage and perception of it.

What version of PW are you running? I'll assume PW 2.3 stable unless you say otherwise. I think you may be right about the editable() check though. Though it looks to me like the module is performing the correct check. I might need to re-think a hook in FieldtypeRepeater to Page::editable. For now, try pasting this at the top of your /site/templates/admin.php: wire()->addHookAfter('Page::editable', function($event) { if($event->return) return; $page = $event->object; if($page instanceof RepeaterPage) { $event->return = $page->getForPage()->editable(); } }); Let me know if that fixes it?

It doesn't support repeaters. If you want to create new forms that don't already exist on the site, then you need to have some kind of administrative access. It does support access control for administrative users though, enabling you to have various levels of administration. For example, you could have a user that can browse entries, but can't edit the form. I'm not sure I totally understand, but if that user role has some kind of access to the admin, you could assign whatever FormBuilder permissions you wanted to them. But keep in mind that administration of forms is really intended for administrators. Hidden fields are supported. Hooks are also supported (like in the rest of ProcessWire), enabling you to modify what gets populated to a field before it gets saved. There is no "edit mode" except to administrators. When a user submits a form, they can't come back later and change their answers, for example. It may be possible but I can't say for certain. I would suggest sticking with whatever code your payment provides gives to you. You could always experiment with it to see if you can make it a FormBuilder form, but I wouldn't depend on it. Payment processors will probably want you to use their code.

Without knowing the full details of your context, you mentioned you are using pagination: I would suggest checking if you need to add a "start=0" to your selector that retrieves the listing of pages for your sidebar.

You'd only want that if you were planning to set the page number yourself from it. ProcessWire doesn't recognize any GET variables in the core. The most valuable presence of that variable [for me] is as a flag that I need to turn on page numbers for the template. Is your template calling render(); on any other pages? Are you using URL segments? Are you setting any of the MarkupPagerNav options manually? What other modules are in the system? There are factors that could feasibly come into play, so I'd need to know everything that's happening in order to say for sure.

It looks like your URLs are lacking trailing slashes. I would try to enable trailing slashes and see if that fixes the issue. I only set my templates to omit trailing slashes for certain instances, like for a /sitemap.xml template, for example. I've not done extensive testing of the language-support modules on templates that are set to exclude trailing slashes, so it's possible there may be issues there.