teppo

Just checking: are you trying to embed actual Admin UI (the admin tool you use to manage PW content with a browser) within Phalcon's admin pages? That's the idea I'm getting from your post and if that's the case, it has very little to do with API and bootstrapping. By bootstrapping you gain access to ProcessWire's content via API, i.e. you can use wire('pages')->find('...') etc. in external code. Admin, on the other hand, is best described as an application built on top of ProcessWire's core (and thus it itself uses the API that ProcessWire provides). If you want to embed the entire admin tool into another application, you've got several options: embed entire admin tool with an iframe (not exactly a pretty method, even though individual pages in ProcessWire's admin can actually be embedded as "modal" views by using GET param 'modal', e.g. example.com/processwire/page/?modal=1) redirect users to said URL directly (if I'm reading you correctly, this is what you're doing right now) create a custom admin page to the ProcessWire site for managing content and embed that (most likely still using an iframe) create a custom application within Phalcon's admin page that bootstraps ProcessWire and uses it's API to manage content (this would probably be the cleanest solution, but I've no idea how Phalcon really works so can't really provide any additional pointers)

No, not by an URL. That'd be a huge security issue, among other problems, since by bootstrapping ProcessWire your script essentially gains superuser permissions.. Bootstrapping generally requires the sites to be on same server, so as long as that's true this isn't a problem. If they're hosted on different environments, you'll have to mock up a public API of sorts to share data, provide views that are embedded via iframes.. or use Pages Web Service to connect the sites.

@Neeks: which ProcessWire version are you using? WireMail was introduced in ProcessWire 2.4.1, which means that you still need current dev branch to run it. I'm assuming that this is the problem. Either that, or there's something wrong with your ProcessWire installation (less likely).

Anyone who has told you that you are The big lebowski? I like to create graphics that is all. I can see the resemblance.

@djr: first of all, welcome to the forum! Very interesting first post you've got there I may be the wrong person to comment on this, as I haven't had much time to think about these kind of changes (too busy building stuff on ProcessWire to spend time thinking what to change about it, I guess) but your idea made me wonder .. how could selectors work properly with such a structure (not knowing for sure that a specific field behaves same in different places sounds like a problem) and what kind of effect would it have to scalability and performance (I'd imagine this leading to tables with hundreds of thousands or millions of rows quite easily, which could become an issue considering overall speed, indexes etc.) Current database structure works quite well in both respects, so this is definitely something that would have to be considered carefully. Other than that, I'm actually not entirely sure that we're on the same page here about some of the things you've mentioned in your post: You mentioned that this way fields wouldn't "have to be global constructs", yet I see that as a good thing. Reusable fields rather than page-specific ones. I'm not entirely sure that I'd prefer to have field schema on the disk, even if it makes duplicating that schema in another installation in some ways easier. One of the key strengths about ProcessWire, in my use cases, is that I can very rapidly build new data structures with the admin tools it provides. How well would that be in line with having that structure as files on disk, I wonder? They're definitely not mutually exclusive things, but don't seem to fit that well together either (though perhaps it's just that I can't see it yet!) Anyway, interesting idea and definitely a good thought provoker

@Craig: that's a good idea and the script looks OK to me. Just some quick observations: This doesn't seem to replace index.php, which does sometimes change (though very, very rarely, so perhaps not a problem at all) Same thing with .htaccess, which could be even more problematic, since each site may have custom settings here (diff+notice?) Also, if you're hosting multiple PW sites in the same location, generally speaking I'd suggest shared wire directories. Symlinks are good for that. This is what I've done to make upgrading a larg(e/ish) amount of sites at once feasible. Anyway, great to see how others are solving this

Thanks, added

@Manfred62, I posted a new thread here: https://processwire.com/talk/topic/6850-module-inputfield-trumbowyg/. Is it OK if I add your translation to the langs directory of the module?

This is an inputfield module integrating Trumbowyg WYSIWYG editor into ProcessWire, quickly hacked together after some discussion at the Redactor thread. Trumbowyg is a light-weight alternative to more feature-rich editors, such as CKEditor or TinyMCE. Both this module and Trumbowyg itself are still in alpha state. Customisation options include only a subset of what Trumbowyg provides, more will be added in the near future. Also, link and image features as seen in other RTE modules (TinyMCE and CKEditor) are not implemented yet. The module is available at https://github.com/teppokoivula/InputfieldTrumbowyg.

@adrian: I'll take a closer look at that tab issue soon. About the link dialog, I'm not really sure -- it's probably the same thing as with image dialog, that it should be replaced. Too bad, since these super-clean dialogs are part of what makes Trumbowyg such a pleasure to use The scope of Trumbowyg seems pretty limited for the time being and for an example I haven't yet found any 3rd party plugins for it (regarding paste buttons and "pretty" code formatting). I'll take a closer look ASAP and see if there's anything available, otherwise might have to cook something up myself. In the meantime I've added some basic config options to the module. Edit: tab issue should be gone now. Forced higher z-index value to fullscreen Trumbowyg editors.

@Manfred62: https://github.com/teppokoivula/InputfieldTrumbowyg. Just for testing, though, it's far from polished (mostly just a quick fork of InputfieldCKEditor with 90% of everything stripped off). What I'm not really sure about, should this become a "finished" module, is how the images should be handled? Trumbowygs default image tool is clean and pretty, but doesn't really make sense in ProcessWire, so I'm thinking that the image plugin from other RTE's should probably be ported here or something like that..

@dazzyweb: I'd assume so too.. at least as long as you're willing to swallow their other requirements, such as the "fair use" clause accompanied by statement that they alone decide what this "fair use" consists of. I for one wouldn't, but that's just a my personal opinion. There's a whole world of difference between proprietary and free software and I know which side I prefer

As harsh as it may sound, I'd say that this isn't something we can affect, and thus not something we should worry about. The best we could do in this regard would probably be adding some sort of indicator to admin whether a specific module is found from the modules directory or not, just to make it obvious that you really are on your own there

@adrian is right; apart from sending loads of email, external services make it much easier to get your messages through. Setting up a mail server is simple, but there are lots of factors that matter when it comes to spam prevention. Formatting and encoding everything properly, having correct DNS records (SPF etc.) and configuring the server itself are (usually) no-brainers, but things like age and reputation of the server also affect scores.. and of course there are various blacklists and whitelists in use too Based on my experience so far, I'd never recommend relying on local mail server or putting one together yourself if it's critical that the users receive messages correctly 100% of time. In this case I can't really say if it's a critical issue if one or two people here and there don't get their messages -- sounds to me like it wouldn't matter that much, but you'll probably know better. Even if you do go with your own, local mail server, at least check it with something like http://mxtoolbox.com/diagnostic.aspx. Tools like that can check that your IP isn't already on one or more blacklists and also make sure that you've got most other basic things in order. Hope that helps a bit.

I get that this is just a small part of a much larger issue, but as a concrete suggestion to a concrete example, there are couple of ways to achieve this: a) they've got a very sophisticated platform of their own, b) they're using one from elsewhere (such as Shopify) or c) for that price they install an out-of-the-box e-commerce solution, do minimal work on it and that's it. Not trying to be depressing here, but if an out-of-the-box solution really what the client wants and needs, that's what they should get. If you want to compete with companies like that and offer your services for clients with such needs, I'd suggest looking into existing solutions -- preferably ones provided as hosted services. If a client wants something entirely customised to their needs, I can assure you that no one can provide it for 399€. Not unless they're counting on making profit from the monthly fees in a long run, in which case the price of the project itself can be much lower than what it costs for them to build. I still very much doubt that anyone would do a >10K€ project for <500€, that's just too much of a stretch. The key here is that uniqueness, authenticity, adhering to specific requirements -- and generally speaking any work that requires involvement of a real person with real ideas -- cost. You can't get all that for couple of hundred euros. For the clients that appreciate this, a bulk product just isn't going to cut it. For those who don't, it's probably pointless to even try to sell it. Out of all the great posts on this thread already, I really liked what @yellowled said about "saving them time, effort and nerves". That's one heck of USP (as explained by @totoff) if you do (and communicate) it right. As another concrete example, we've been involved in projects that have literally cut a weeks worth of manual work to an hour or so of waiting for a background task to run. It'd be pretty hard for a client to not value that. I'm sorry that things are difficult for you and really think you're right when you say that people don't appreciate craftsmanship much these days. It's a sad thing, but all I can say is that you'll have to either find a way to provide good quality with minimal effort (out-of-the-box services) or find a way to attract clients that do appreciate this. I know that neither is really an easy way out, though.. (For the record, I work for a company that provides web-based solutions ranging from the most basic self-service platforms for small companies and individuals to entirely custom-built ones for large corporations, cities/municipalities etc. For some clients we handle everything from content to marketing and some prefer to do these things themselves. There are clients for all of our products and none of them is perfect match for all of our clients.)

I'm the last person to stand up for WP (seriously), but still have to point out that neither of these are really issues with WP itself. In fact most of WP problems I've seen have been related to 3rd party plugins/modules. I'm not saying that it's not the fault of the system in some way, as they really should provide a safe platform for 3rd party extensions to build on (and clearly that's not always true in the case of WP), but they (WP core developers) can't be held responsible for whatever crappy code people implement on top of the good parts of that platform. .. oh, and my main point is that this should really serve as a warning for us too: it's entirely possible, if not exactly easy, to create modules with vulnerabilities on top of ProcessWire. As the amount of modules grows, issues like this become more likely and thus we (module authors and users alike) really need to take an active role on preventing them. IMHO.

$page->pattern_type should return an instance of PageArray, which won't have field "title" -- or any other fields for that matter. PageArrays are collections of Pages, and Pages are the ones with fields (and in any case you wouldn't be able to iterate title field as in your example). Try iterating Pages contained in that PageArray, like this: foreach ($page->pattern_type as $pt) { echo $pt->title; }