ryan

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.

I've got TinyMCE 4 working with PW locally on my dev branch. They've changed quite a lot on the API side, but it all seems like improvement even if it does require lots of changes to code that uses it. In some ways it seems like a different product. I need to put more work into supporting all the other options we currently support in TinyMCE 3, but so far TinyMCE 4 is looking very good.

It actually shouldn't matter whether it's in a repeater or not. Repeaters don't change the type of any fields. But your code above has "->->" which looks like a typo? The nice thing about repeaters is that they really aren't anything more than a regular PageArray like any other. An alternative is to set $user->language to the language you want the field to return its value in, before you retrieve the value. Then return $user->language back to the language it was before.

I've pushed and update to the dev branch so that sorting should now work across languages. Previously, calls like these would still result in the returned pages being sorted by the default language field, regardless of the user's language: $pages->find("..., sort=name"); $pages->find("..., sort=title"); $pages->find("..., sort=pageref.name"); $pages->find("..., sort=pageref.title"); // and so on To demonstrate the problem, lets say that you had these three pages: /numbers/one/ /numbers/two/ /numbers/three/ In Spanish, those pages would be named: /numeros/uno/ /numeros/dos/ /numeros/tres/ Lets say I executed this in English (my default language): $pages->get('/numbers/')->children('sort=name'); The result would be alphabetical: /numbers/one/ /numbers/three/ /numbers/two/ If I executed it in Spanish, the order would still be the same, sorted by the English spelling (which is clearly not correct): /numeros/uno/ /numeros/tres/ /numeros/dos/ They should be sorted alphabetically by Spanish instead. With the latest commit to the dev branch, they should now sort correctly for the given language. Meaning the Spanish results would now be in this order: /numeros/dos/ /numeros/tres/ /numeros/uno/ The scope of those goes beyond page names. This also affects multi-language text fields. So if you've got a multi-language 'title' field for instance, you can sort by that, or any other multi-language field you are using, and the sorting should work properly now. It does not yet work with language-alternate fields, though I think it's probably unusual to use those fields as sorting keys anyways.

I think the issue is that you were specifying "comments.text" rather than just "comments". You don't need to specify a subfield when searching comments. This should already work (and it is implemented in 2.3): $pages->find("comments*=SomeStringHere, sort=-created"); There isn't actually a "text" field in the DB, which is why your search wasn't working (it's called 'data' instead). I have gone ahead and pushed an update to the dev branch that looks for ".text" and substitutes ".data", so that nobody else should run into that issue.

Same thing this time. It's odd, I've not ever seen a PDF do this before.

Backwards compatibility is always the concern with changing stuff like this. But we actually have FieldtypeConcat which provides a way of achieving the same thing.

What module? I'm thinking this is MarkupPagerNav, but want to double check. I can't think of any reason why you'd have to allow page numbers in the child page, unless you are doing some of your own page renders that themselves do pagination: $child->render(). Is your template calling render() on any other pages? Might be good to see the template code where the issue appears, as well as your code that outputs the pagination.