ryan

TinyMCE can be maddening sometimes in this respect, as I've tried adding allowed attributes only to have TinyMCE refuse them for some reason or another. It's almost as if there are some other rules at play overriding user defined ones. However, if you set TinyMCE to allow everything then it usually works. The way you do that is to set your valid_elements to this: *[*] Not saying that's a good solution, but it works in a pinch and sometimes it's the only way I can get TinyMCE to cooperate.

Sounds like they could be Apache internal server errors. You might have to go to the Apache and PHP logs to see what's causing it. But in my experience, it's most often something in the .htaccess. When I run into an unexplained 500 apache error, I'll usually start commenting stuff out of the .htaccess file until it starts working, in order to isolate what the problematic directive is.

Interesting. I guess I'm not familiar with that Flickr BBCode. Can you post an example? I'm betting we can get Hanna code to make it happen.

This is an error MySQL would report if there was no "data1439" column present in the field_title table. I'm guessing that 1439 is the ID of your "default" language. There was a bug in PW related to this that I fixed recently (within the last 3 months I think). Double check that you are using PW 2.3. If you are already using it, you might try switching to the dev branch (at least to test) to see if that fixes it. Please let me know what you find.

I'm pretty sure that a Repeater can't be used for Inputfield forms outside of ProcessPageEdit. It's sufficiently complex enough, and tied into its storage engine (pages) that it can't be used for other forms. As a result, if you need something similar, you might have to bundle your own input type into an InputfieldMarkup or something.

That's true for a couple of those ID definitions (mainly 1 and 2), but for most it's ok to change them when/if you need to. The 404 page ID is one where there shouldn't be any problem with overriding it.

What version of ProcessWire? Check your /site/assets/logs/errors.txt and/or edit your /site/config.php and enable debug mode by setting the $config->debug=false; line to true. One of these should reveal the error, unless the internal server error is coming from Apache rather than PW.

Sorry, I should have realized and mentioned: the code I posted requires ProcessWire 2.3 and PHP 5.3+. Thanks to Soma, you've also got the version that is compatible with PW 2.2.9 and PHP 5.2, above.

I just used the Redirects module a couple weeks ago (for cmscritic.com) and imported a hundred or so redirects from a CSV. I haven't run into either of these issues. You might want to double check that the CSV you imported from has proper linebreaks?

Kent, that's correct–I'll update the readme file. The term "name" is set to the name of the Hanna code. This is provided to the PHP so that it can check the name of the code, just in case it needs it. Likewise, it's preferable not to use any API variable name for your attributes either.

Not sure I understand the question. What BBCode from Flickr?

You would want to include a "start=0" in a find() call that has a "limit=n" in its selector. This would be only for the results you don't want to paginate. I'm thinking this is the line: $posts = wire('pages')->find( "template=post, date>=$firstDay, date<=$lastDay, limit=$_limit, sort=-date, start=0" );

This capability is actually built into FormBuilder. When editing your form, go to the "settings" menu and check the box for "Preset field values from GET variables". Then on your page that has the form, just specify the GET variable you want to populate in the URL: /path/to/form/page/?subject=subject1 When you view the form (embedded with option A or B) the value will be pre-selected.

What about dropzone or one of these other ones Kongondo posted in the other thread? http://processwire.com/talk/topic/3761-dropzonejs-and-file-uploads/?p=36705

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.

You can, but you should tell ProCache the names of your GET parameters so that it won't attempt to cache those pages. You can do this in the ProCache settings on the bypass tab. See attached screenshot. The default setting is "*" which means that GET requests with variables aren't ever cached, regardless of the name. This is a good setting to keep if you don't want to think about what the GET variable names might be.

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.