Joss

Hi Diogo - I thought you had gone home! All that does is print <i class="icon-edit"></i> (As in you can actually see it) and replace the "Edit", though at least it does not duplicate itself all over the place I have just tried html instead, and that is better, but I need to rescue the original text

Hi there JQuery shaped people! I need to prepend something to an element on the page list, but because of the way it is working, I need to check whether it has already been prepended! So This is what I am starting with: <li class="PageListActionEdit"> <a href="/siteadmin/page/edit/?id=1">Edit</a> </li> And I need to end up with <li class="PageListActionEdit"> <a href="/siteadmin/page/edit/?id=1"><i class="icon-edit"></i>Edit</a> </li> Since this is part of the ajaxified page list, I can't simply do this: $('.PageListActionEdit a').prepend(' <i class="icon-edit"></i> '); Because it will just add another one on every time I click a page. I assume this is probably using either .not() or .has() to make sure a particular version has the Icon, and if so, doesn't prepend it, but I cant get it working! Help! Joss

Nice one pete! Can we put puppies on it?

Okay, that sort of worked. I got all the required mark up in, but it messed up the way the actual page list worked. Everytime you clicked on a child page, it just added more and more buttons till I had a page of them. Oh well.

Thanks Diogo! That worked. I will now try the series of bits I need to get the effect (this may horribly wrong.....) Joss

Hi Wanze Because this is a theme, I cannot hack anything but need to override instead. Basically I need to wrap the page list actions in some html and css to make it work differently.

I am having trouble modifying elements on the page list in administration. I am trying to do this: $('.PageListActions').addClass('test'); (Actually, I am trying something more complicated - but this is a simplified example just to work out the problem) The problem is that it is simply not taking at all. I have used similar bits all over an admin theme, but when it comes to the page list, it all falls over - or rather, does nothing at all. I have tried both $(document).ready(function() { and $(window).load(function() { and stuck it all over the place, but to no avail. I am assuming it is something to do with how the list is loading, but I dont know what to do about it. If I work my way backwards, I can addclass to PageListRoot, but not to PageList, which comes after the loading span. Anyone got any suggestions?

Goedenacht, Martijn

oh! The button says "Like?" I must invest in some new spectacles..... (And thanks for your menu help anyway!)

Ah, that is exactly what I need (or will need) later this year for something. Nice one!

Hi Martijn I think I mentioned that. That is the best way of creating a library since it uses the native PW PAges structure, is automatically categorised by the Tree (to a certain extent) and is accessible. However, it should also be accessible for an images field and not just for TinyMCE and, ideally, you should be able to upload to that pages tree even though you are on a completely unrelated page. The existing system is part the way there already really, at least philosophically!

Ooh, just learned something! Thanks.

*puts unfinished novel back on shelf*

Hi Christoph Although you might hide the parent (and therefore the children will not appear on the menu) the children and the parent are still published. If you look through the Cheat Sheet you will see you can call a specific page and then the children. So, for instance $pages->get("/path/to/page/")->children - will retrieve all the children to a specific page. Now you can create a foreach loop to retrieve the fields you require from the children and display it however you wish. http://processwire.com/api/cheatsheet/

I agree - I like to make sure I have lots of Soma's modules installed to see exactly how much trouble I am in ....

Now, that is a challenge. The last proper development report I wrote was 70,000 words..... (Damned thing didn't happen either!)

I must admit that I have an installation that I simply use for trying things out. It is useful because as I try the next thing, I have plenty of examples of other stuff to make sure it all works together. Lots of broken and tatty bits too - but it all adds to the flavour. What you probably want is a profile with your favourite modules pre-loaded, quite a few test pages, repeater fields, assorted image fields and so on (so, a typical site) then use that as a test bed.

Hi Thomassausen That is a great way to start - and a nice clean site, by the way. I am just doing a similar exercise on my own portfolio site .... though I keep getting distracted playing with functionality that the site will never use! Joss

hehe ... is that a poke at my short and concise posts???

Oh, please - don't introduce WillyC to the concept of Finnish compound words!

This was my point above. For such a system to be successful it is vital to have active mods that can do some cross posting, even if it is just a post that says "interesting conversation on German forum about indexing - get your dictionaries out" This does take a lot of management though and there is no tech workaround or anything clever - it is boots on the ground. There is another argument that says that you just keep the forums in one language - but that tends to do two things: It alienates users, and the better ones wander off and do their own thing. Anyone who knows anything about Joomla may have come across the Brazillian (I think I am right about that) Joomla site that they set up independently. A couple of their main users popped into one of the English forum and it soon transpired that they were having far more intelligent and forward looking conversations than the English speaking developers, and coming up with seriously good solutions to problems - and yet were being completely ignored/overlooked. A big loss to the overall project that.

*whistle whistle whistle.....*

The community issue is separate I think. I am a great believer that, once a community gets big enough so that it is not like a cosy family any more, it should be very separate from the main, promotional site. That means that it might have a common logo and possibly corporate colours, but other than that, its design is aimed at community. In the case of national websites, they would, by definition, be promotional sites (plus direct translated documentation) - they can have their own unique identity, but must follow some basic rules and be approved centrally (as any company with multi offices does). The community site, however, should be one central resource, albeit with language sections. That way, those that are multi lingual would be able to talk on native language forums and others that they can understand all in one place. Or use auto translators to understand posts if needed. But they remain part of the entire community rather than being off in another place entirely. (Note: it is vital, in these sorts of forum, that moderators duplicate important announcement posts across all languages. Time and time again I see this not done, which leaves one community feeling like they are also-rans. Multi lingual communities can work very well, but they need lots of management).

Hmmm, Okay, this is just me thinking, so probably wont make too much sense. Here are some thoughts #### If you search via pages/templates, then you have a potentially complicated search. However, if you search the other direction, so search any table that is an images or cropimages table, then the search is less of a headache. #### We could add a reference to any media upload that is stored in a central table - so basically, we have an images_index table and everytime you upload an image, it puts a reference in that table, including a note as to the first page it was associated with (this is so it can find the file) We are not adding to the fields in any of the images tables, they stay as they are, just duplicating the reference elsewhere for another purpose. This could be done as standard, so that if later on if a person changes how they are working, the references are already there. (Note: it might be useful to have a script that can search everything and create the table if you are adding this to an existing site) ### Images (and other media) are different from other data in that they have an associated file. Since these are all kept in one place (assetts), these are easily sourced. There is already the file manager plugin that does this. ### There is an issue with deleting a page and therefore deleting the image. May be that should change - the image file stays and just becomes an orphan. If another page uses it, then it gets a new mummy! (sorry, bit sick?) ### I don't think we need to add an extra field for categorisation - just be able to upload an image to a page that is categorised. So, if you upload to the page you are on (say a blog entry), then the category of the image is, implicity, that page. However, if you have created a library, and from the blog entry you are able to remotely upload an image to a page in that library, then the category will be implicitly that library page (and its hierarchy and anything else associated). That seems to be the easiest way to do this. You can do that manually at the moment. Create a library for your images with a top level hidden page and then a tree beneath that. Choose a page in that library and upload an image Save and Close Go to your "blog" page Open the image field and find the associated library page Select the image. So, instead of that, you would Go to your blog page On your image field, you have a choice (radio buttons or toggle)Load Image to Current page Load image to Library (either can be set as default) If a single destination has been pre-selected in the field settings for the Library choice, then you are ready to go If a choice of destinations have been preselected, then when you select the library choice, you are automatically asked to browse to the destination (or whatever is the neatest and simplest way of presenting this) Drag and drop your image(s) and use it. This way, images are all stored just as they are at the moment - it is just the action of storing them that is changed. The one complication is the Thumbnails module (which I love) It would be nice to have this working the same way including the thumbnails. It is probably not difficult to do, actually, but care would have to be taken with how the thumbnails module is set up (what thumbnail settings) so that it matches the page you are using. Well, the admin should be left with SOME work to do!! And goodness knows how that would associate with TinyMCE (which it doesnt at present) Okay, all kinds of bits there .... sorry!