LostKobrakai

Exactly that happens if a client goes to your central media manager and deletes an image. It's a natural flaw of RTE's that they store filenames which break if one deletes the file. A RTE is not an image manager. It's a texteditor. That's why you always need some extra place where images are stored. In either way: You need to communicate to your editors where images are stored, so they can manage them (and not only upload till extinction). If these images are in the page, they are editing, or in some central hub shouldn't matter to them to much. That's where I personally think it's easier to tell them the images are stored right next to the RTE they want to use it in, instead of some other place, which is quite unrelated to the actual page. It's really the same problem, only the images are displayed in different places. You can read Ryan view about that and how ProcessWire handles deleted and updated images here: /blog/posts/quality-assurance-for-images-in-rich-text-fields/

I think it's actually more easy that way. If you're using images in different contexts, so that you need separate image fields, than you'd need to differentiate them in each other system as well. And I find different image fields for different contexts much more logic than tags, or categories, or really anything else where all images are equal by default. Edit: The fact that images uploaded to the RTE appear in a separate imagefield as well (for storage) is not that hard to grasp and explained once should not make any difficulties.

I think currently the upload in the modal does only "emulate" the upload while via javascript the image is added to the page itself. Therefore you can't "hide" the field, as this actually keeps the field from rendering all together, so the upload via javascript can't find a field present in the page. What you can do is use the collapsed option. the field is collapsed to the title/label only, while the inputfield is still rendered and targetable by any javascript.

This thoughts have come up every now and then here in the forums. But after some time of getting used to this most people do like the fact that files are just where they are needed: stored in the page which it belongs to. It's actually more powerful and structured than having just a single bowl of files. There are also no plans to change the way images are stored. To make this more concrete: An RTE field cannot store any images. Most cms's hide that fact, by including their media managers directly into it, but this decouples the images completely from the page structure. If you're worried about your clients being confused by this, you should be able to hide the images field for them, as the latest dev version added the ability to upload images directly from the RTE images modal. The flexibility comes if you think about multiple imagefields. E.g. one for the big heroimage (single), one for the RTE images (mutiple) and maybe one for generating a optional gallery (mutiple). Each field for it's own concern and seperated by the page they are used on. If you compare that to a media manager where all those files are bunched together, I would rather take the processwire approach. Another example: Think of a list of pages representing different clients of the website's owner. All of them have a logo and semantically the logo belongs to the client, that's why it's on a page with all those other informations like names, address and stuff. If you would link the image from a media center you would need to maintain the images seperate to the clients: Go to page, change the name; go to media manager, change the logo (if it's that easily replaceable). In ProcessWire you can change both in one place and other pages using the image will update as they most likely will be field dependent (if used via the api, they are for sure) and not dependent on a specific imagefile (don't know if the RTE's do update automatically).

From a quick look in Page.php it sees this should be tracked. See those: https://github.com/ryancramerdesign/ProcessWire/blob/576a5d30153f045daa94a136a6ba981650632b26/wire/core/Page.php#L908 https://github.com/ryancramerdesign/ProcessWire/blob/576a5d30153f045daa94a136a6ba981650632b26/wire/core/Page.php#L422

What I could imagine is using processwire as dashboard for those information, but the tools to analyse these things just wouldn't benefit from processwire itself.

I've already posted this in the Hanna Code support forum, but I'll add it here, too. I'd really like to see description, because together with the "only be able to see the list of hanna codes" permission it would make for a good and easy to set up way for clients to look-up the available hanna codes. Without the description it may be still hard to recognize the codes for less experienced users.

So yeah, nope, it's not that easy. Also 5 requests/second would mean 100 seconds for 500 addresses, which is enough to exceed the 30 sec execution time of a standart php installation. For more details see here: https://developers.google.com/maps/documentation/geocoding/?hl=en#Limits (the german one isn't as detailed, but also has the part about using it with a visible map)

Judging from the module description I'd say it does not work. Batch geocoding is a payed service by most providers. The only one I found is MapQuest, which provides a batch api with up to 100 addresses per request, but still no parallel requests like it's the case for all other free services. Edit: Most likely such a thing would clash with the max_execution_time of php for most users.

This fills in the field name automatically and the return shouldn't be necessary as the function is at it's end and does not return anything. public function formatValue(Page $page, Field $field, &$str) { $str = str_replace("<p>", "<p class='{$field->name}'>", $str); }

By art-directed to you mean per-page or overall custom css/js/html? To begin with the whole frontend is custom in processwire. The cms doesn't enforce any markup, while a few module happily do generate markup if you wish, so you've the full control. If you need to be able to change presentation from the backend, build it that way. It really depends on what exactly you need.

Did it help?

Maybe there is a way, but wouldn't it be way easier just wrapping the output of this field in something with a class and use this ".summary p{ }"?

Did you try different browsers? I noticed rendering bugs in my WIP of my fields-to-templates stitching module and in this form the left border of fieldsets do get lost if I open them from collapsed mode. As I switched from Chrome to Firefox the issues where gone. Strangely the borders are there after initial render (collapsed) but are lost for the collapsed state as well after opening the fieldset once.

I don't have an overview on what exactly you're using to render the mentioned _main.php. You can either use a if else statement in the _main.php and dependent on that include 2 different php files for the layouts or you need to take a look at the ProcessModule you're using to render it and see if you can change the file by hooking there. Or at least tell us here, what you're using, so we can help there.

Even security questions can be dangerous: http://www.ibtimes.com/elaborate-hack-steals-rare-twitter-handle-n-1552045 What annoys me personally the most about them is, that they often are questions, which you can hardly answer in a single word and matching the provided sentence, when I want a new passwort, is almost never successful.

That brings it's issues, too, see here: https://github.com/ryancramerdesign/ProcessWire/issues/969

Just edit the url of the "Admin" page in the pagetree.

Updated the module to show the right access rights for superusers (can access everything no matter what) and access rights inherited to every user by the guest role. Also changed the modules name and will post it now to the modules directory.

It should be added, that this only works as long as the PageArray for the foreach is sorted by editorial, otherwise it would be needed to search the whole $editorials array for duplicates and not only the last item.

It's an interesting topic you've mentioned here. I'll just want to take some of your issues with the current system into my perspective: Right on top of the Page Class you'll find this. It's not the most verbose, but a simple search for render() will get you there. Also I'd think that there's a reason, why the function isn't in the Page Class. /* Methods added by PageRender.module: * ----------------------------------- * @method string render() Returns rendered page markup. echo $page->render(); I can see, why the first function could be difficult to beginners, as it could cause problems, if one would need the hook to run after or before. But I just never used addHook() in the beginning, because I wanted to be sure it's running before or after the hooked function, because there where lots of other potentials of error, so I tried to at least force the hook to run on the expected time. Can you elaborate on that? I really can't see, how those underscores would alter the ability to find a function. That could also be the case with the current hooking system. Page::render() could be a function of Page, but it's "added" to the object. I don't know the event system you're mentioning, but if it needs a base function to dispatch an event, how would one add new functions, that aren't there ahead of time? Additionally by now one just adds the underscores and doesn't have to care more about anything and it's hookable. If I understand you right, this wouldn't be the case with those events.

You could build this by yourself with language alternate fields and fieldset tab: http://processwire.com/api/multi-language-support/multi-language-fields/#language-alternate-field-values. It's a lot more clicking to get this does, but it does work. I think a automatic way wouldn't work as easily, as you can't depend on users having only a single tab with fields and duplicating 3 or 4 (or even more) tabs for each language will quite fastly lead to something, that's less clear than the current way. Maybe a "global" switch to change all fieldtabs of a page to the selected language would have the same effect, while keeping the current structure.

You can always use this " 'requires' => 'PHP>=5.4.0' " (I don't know if it works without the minor version number) in the module's info. This way the core can still cater to a broader audience.

Yeah, as the site does not need super dynamic content it does load the needed json only once in 10 minutes. After that it just reuses the previous response. Until now there isn't even a server side caching.

As always to occupied by actually writing the thing