adrian

Just noticed that: $config->scripts->append($config->urls->adminTemplates . "scripts/cookie.js"); results in an error, because cookie.js is not included in the theme download.

Sorry Ryan - I think Chrome or my internet connection was bogged down with something else. I had uninstalled the module and tested again and the images showed within a few seconds, so I had assumed the module was generating images on the fly. I have reinstalled now and restarted my browser and it seems fine now. Am I correct in assuming that no images will show until all have been loaded? This might be an issue still if there are lots of images on a page - a loader/spinner might be nice. The only other comment I have is that when there is only one image on the page, it stretches it to full width which looks a little ugly. Thanks for the great addition.

Hey Ryan, This looks really nice - definitely a big improvement on the existing layout. Only catch I am seeing at the moment is that with really large images, it takes a long time (almost a minute in one case) to load the thumbnails. Obviously I am not displaying these high res images on the site, but they are being made available for download - linked from an automatically generated screen-sized version.

Thanks for all the feedback everyone. There are a few reasons I didn't go with JS (which I have used for several years for making image captions from ALT fields). I wanted to use the Image description field that is with the image in the images field, rather than the one that is added when inserting the image into the RTE (and becomes the ALT tag). This is what Lars asks for in post #3 above, but more importantly, this has the advantage of keeping the ALT for its intended purpose which is to describe the contents of an image for screen-readers/search engines - eg. "clothes on a clothesline". This allows the image caption to be more relevant to the context of the image in the text. eg. "Hanging your laundry outside saves energy, money, and the environment." I also wanted to be able to define which images get the caption added. This way you can still maintain your accessibility (for screenreaders etc) by always having an ALT tag, but leave the description field blank if you don't want a caption. I wanted to restrict the the production of captions to textareas only, without relying on a container div for determining which images get processed. Doing this server-side just seems cleaner somehow Teppo - I could just as easily have used a regex, but domdocument just seems easier to me when it comes to tasks like this. I am still looking for a way to solve the issue of two images with the same filename somewhere on the site. Again, this only comes up if your pages are drawing content from other pages, but I do this often, so would like to solve - any ideas?

Thanks Ryan, I glanced over it and I think I have the idea on how to set up what I have been talking about. Not something I need right now, but I am sure I'll use it in the near future.

Thanks Marty, I think it's a reasonable start. It would be a lot simpler to just go with the description field at image insert (ie the resulting ALT tag) as this avoids all the issues of searching through the page tree looking for the image description by filename. I'll wait for a little more feedback and ideas for solutions regarding the duplicate image filename issue and then I'll start adding some config options.

I have hacked this module together which seems to work pretty well. It wraps the image in a div and grabs the caption from main description field within the images field. I think this is what you were looking for. This is all done with PHP, rather than JS. Probably not a very elegant approach, but I needed something quickly. After some feedback, I would like to add some config options for formatting of the caption and whether you want the caption from the images->description field (as it currently is), or simply the one that becomes the ALT tag in the RTE textarea. Also, the module should perhaps named as a textformatter? Any thoughts? EDIT: I just replaced the attachment with v1.01 which now handles pages that include textareas with embedded images from other pages in the tree. One concern with this is that if an image with the same filename exists anywhere else on the site, it won't know which one to use. Not sure how to get around this yet. EDIT: 1.02 makes sure there is appropriate content on the page to prevent warning error. EDIT: 1.03 makes use of some code from Martijn's Image Interceptor to grab the id of the page the image is from, to deal with the potential duplicate filename issue. Available at: https://github.com/adrianbj/ImageTextCaption

Hey Nico, You have a couple of instances of $config that need to be changed to wire('config') Thanks!

I haven't ever experienced this error, so maybe there is something else involved, but you have a semi colon at the start of the line which means it is commented out and not used. Try removing the semi colon and also be sure to restart apache to have the changes take effect.

I think you're referring to select options (ASM etc) and the page fieldtype and how best to set up and where to store the page tree that contains the options for selecting from? alevine - is that the gist of the first part of your question?

Yeah, I know. I guess the title of post isn't really accurate as at the time I didn't realize that removing it completely provides different behavior to having it unchecked. I guess I think the page-edit should not be affected by page-publish. Maybe there needs to be a page-edit-published as well to provide the scenario I am talking about. So you could check page-edit, page-edit-published and uncheck page-publish. Might be a better way to achieve this, but you get the idea.

Hey Ryan, that is exactly what it is doing for me right now too. I can only assume that right now I need more sleep, but I'll keep an eye on it.

Hey Soma - that is the permission we are talking about. Once it is set up, but unchecked, it overrides the ability of a user with page-edit to edit a page that is already published. Hence there doesn't seem to be a way to prevent a user from publishing a post, while still giving them the ability to edit a published post, which seems like a valuable scenario to me.

That is actually the permission I am referring to above as "Publish/Unpublish" - that is the title it is set to. I didn't realize that removing the permission would do what pogidude describes. There still doesn't seem to be a way to set someone to be able to author and edit published posts, but not actually do the publishing - am I missing an option somewhere?

At this point I haven't really thought about the workflow, but I think there might be some room for improvement there. Initially, I am just wondering if it makes sense that a user who has editing rights should be blocked from editing a page, just because it is already published - maybe it is more of a terminology issue for me at the moment.

I wonder if this is completely logical. I can imagine a scenario where I have a user that I don't want to have permission to publish a page, but I am happy for them to edit a page once it has been published. Not really a trust issue, but rather want to ensure they can't accidentally publish a draft until it is ready to be public. This is currently a theoretical scenario for me so I haven't gone looking for solutions, but just want to raise the issue and see what the consensus is.

I have been using dlvr.it - I found it was more reliable handling at ensuring the images made it through to FB. I had some troubles with RSS Grafitti. There are lots of other services out there for RSS to FB/Twitter, which seems like the easiest approach.

I think this might be by design, but when I go to link to a file from a RTE field, it doesn't show files unless they are in fields named "images" or "files". Shouldn't it find all fields that have field or image as the field type?

I think the problem is the spaces here: eventStartDate >= $today Try: eventStartDate>=$today Also, in case you don't know about it already, check out this module for testing selectors: http://modules.processwire.com/modules/process-selector-test/

Perfect solution. For those who find this and want to deal with it. In site/templates-admin/default.php, modify this line to read: $last_modified = $pages->find('limit=10, sort=-modified, start=0');

Just discovered a weird bug - If you have more than one page of admin users and you are viewing any page but the first, the latest updates section in the sidebar also shows results from page x of its results. Not sure if this is a general PW bug or something specific to this theme. How does PW generally handle pagination when there are two things on a page that both allow pagination? I haven't come across this scenario before. Anyone?

I wonder if you don't have the Textarea (Multi-language) module installed. It is a core module, but not installed by default. The other thing to try when migrating to new servers is to do a test install (in addition to copying the folders across) so the installer requirement checks are run.

Thanks Ryan, but the 404 page is/was not viewable by the user, so I don't see how they could have changed it. The page they edited the name of also disappeared from the page tree and all the content was actually in the page with ID of 27, including all the uploaded images - which actually even ended up in assets/files/27. I am baffled how that could happen, but it did

Awesome diogo - thanks for the quick fix - sorry i didn't think to look there last night - was too late

Just used this for the first time - so easy! I am using 1.04 with the latest dev (as of today) Thought everything was working great, but then when I went to test to see if general admin users could see it, I discovered that they could see the new page just below "Access", but then when I clicked on it, I get a "You don't have permission" error. I have looked through all the permission options I can think of and can't seem to get it working. Any thoughts please?