Jump to content

Rebecca

Members
  • Content Count

    16
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral

About Rebecca

  • Rank
    Jr. Member

Profile Information

  • Gender
    Not Telling
  1. Why not make the script have variables : ( $language[181] or M_BACK so that there are different language files with defines, you ask php to include your language file. This will make it easier for any of us to translate PW since we would be translating full sentences instead of word by word. This also solves some things like changing the wording on the admin as we might please (by modifying the language file) or even using icons where/if we want. Making this a requirement for modules also means that they will be easily translateable as well.
  2. Oh the tags look pretty in your proposal, the commas are there for easier parsing, right? The thing about having two template levels is an idea about modularization. By defining where blocks would be separatedly from what blocks might contain we would be able to quickly change a blocks content without needing to change the whole template. BTW, there is a way to keep things tidy and PHP even if we implement the tags module, which is to make the tag module just an easy interpreter that can translate my tags into PW proved and approved code. So this: {pages.find parent=/news/, featured=1} <li><a href="{url}">{title}</a> {date}</li> {/pages.find} would become a file like this: <?php foreach($pages->find("parent=/news/, featured=1") as $item) { echo "<li><a href='{$page->url}'>{$page->title}</a> {$page->date}</li>"; } This way the module would not need to be present in a live website and still be the same PW that developers love and enjoy using While "compiling" the parser would call each block, interpret it, and generate the PHP code for it, once you are done, you simply take your site -sans the tagscript module- and upload it and it works Having 2 levels in templates might also mean an easy way to develop custom output templates like RSS, xml lists, json responses etc. What it would mean though is to have 4 (a header, a list, a footer and a full) templates and a way to call them. Think about tinysong and it's API. The searchbox calls a list of songs that match a query. By adding a parameter, you get a different response in a different format (namely JSON). And that's just an example, we could list oh so many others in oh so many other formats... In fact, this could mean that PW would be ready to output in just about any format.
  3. OK then a shorter version: Defining current templates as level one templates (structural), I suggest we make it easier to create level two templates (blocks) as this could make things easier to develop customizations for PW. By doing this we would be able to create RSS templates, Google Maps would be solved by creating a block with the tags needed to render it and taking the data from a "Page" (as we currently call them), featured content sliders, json responses, audio playlists, etc. By using tags, non-php-savvy developers could generate solutions to everyday tasks easily. You are a php developer, organizations would need you keeping the code safe, secure, up do date, etc, and they would task designers and/or website admins (people who aren't always knowledgeable in php) to create level one templates (the outside structure) and level two templates (blocks such as news lists in several formats). Ryan's code is, IMHO, a step in the right direction. Thanks, take care
  4. I understand there are priorities, there are some that you might have overlooked though and this is indeed a possibility, which is why I second the opinion that the roadmap might be submitted up for voting. I've written a couple ideas on how we might make some changes to ease the module development learning curve, there are some UI things that need revision (some of the terms using might lead to confusion or error, there are changes that would speed up usage and even make PW more accessible). So, accepting requests as suggestions, rather than a list of demands, might help us have a smoother relationship and might help keep this community coming up with new ideas. Thanks, and take care
  5. Let me address this A mixture of lack of experience of documentation (as of yet). It might be the case that you didn't want to come out as rude, but just think about it, if piranha and me have come here for information and help, offering us to do it ourselves is not the most helpful response (though, I might add that the clarification of this not becoming part of the core and it probably coming later down the road as a module indeed is helpful). I say this to state my point of view on how we should care what we say here to keep this community happy, helpful and fun Thanks and take care.
  6. Wow, this is really cool! Now this is something I've been giving a lot of thought recently, because I'm rewriting a custom fork of another script: There's content templates and then there's site templates (i.e. site themes). I must admit this was something I hadn't given enough thought in the past. To further explain this: As a designer, I often have found sites that require the typical CMS structure (i.e. a big news corp site is almost always the same, lots of blocks, lots of block positions, etc) which means that I need to determine what goes where and, upon determining where things would go, I end up with a basic wireframe or content skeleton. This structural form will be the basis for the rest of my implementation (and sometimes is the point of departure to determine which CMS I'm going to be using). So this is a site theme to me. This also goes to explain why I proposed the creation of a blank theme, that is, a site structure that can easily be expanded, changed (blocks trading places, etc) and beautified (strictly using CSS, 1 for the structural layout and 1 for the graphical adornments). But then, inside such blocks, you have your lists. All websites are, in essence, lists of content. Lets get back to the news site example and define that we'll have some news reports with video, some with audio, some with pictures and some will be just text (maybe editorials), we'll have sections, tags, topics, as well as the other more obvious fields (date published, author, etc). On our example's structural layout (theme) we have defined that there will be a lot of blocks, and each and everyone of them will be different in a way, some contain pictures and titles, some just a title linked to the full news, some might have an excerpt to the news piece. We might also add a block with tags, topics, a navigation menu with sections and a list of writers with links to all their news posts. Now, the way I see it, this would be level two. In level one, my theme would look something like this: <html> <head>...</head> <body> <div id="head">{b_header}</div> <div id="slider">{b_news_slider}</div><div id="tags">{b_trending_tags}</div> <div id="rnews">{b_recent_news}</div><div="rpics">{b_recent_pics}</div> <div id="rvids">{b_recent_video}</div> <div id="alist">{b_author_list}</div><div id="rauds">{b_recent_audio}</div><div id="topics">{b_topics}</div> <div id="foot">{b_footer}</div> </body> </html> Giving the site's a chance to define a different template to be used by the home screen, section screen, videoplayer screen, single post, etc and also a way to easily customize what goes where, in case the news corp head honchos decide to change the layout, keeping them away from the, more important, level two templates. Level two templates are how we present stuff inside the structural blocks, don't think of them as merely "here, list 5 items" code (this might very well be defined in the level 1 structural templates) but as a way to create the appropriate variations for each one of them so that we can use and reuse them easily. While in the home screen I might present a bunch of blocks, I might need that they are less, or ordered differently, in the section part of the site, or that they have more or less content on them. We might have PW create automatically some of them (single items, full lists, simple lists with just title and link, etc) but we might also have a way for developers to easily create new ones (in videos: preview pic, title with link; in audio: a list with the title and the html tags needed to display an audio player, etc) Another thing we could gain from this is the ability to create custom xml, xslt, json, rss, and other types of pages. The level 1 template would take care of the of the surrounding tags and the custom level 2 template would take care of what goes inside, allowing us to create, for example, RSS lists for all items on our site, or just for the news entries; going even further, this could allow us to also create an xml in the specific format that some video players require. BUT WAIT, you might say this is easily done with what we have already, right? And I can see your point. Indeed this is achievable right now, but (there's always a but or two) you are viewing it from the developer's perspective. The news site wants developers making the script more secure and have more features. So it will be up to the designers and website admins to keep making changes to the layout. At least that's been my experience. In any case, this is just my thought on where PW might want to be moving, keeping things simpler to designers (all blocks and layouts can be made with almost any wysiwyg editor) while keeping things flexible and powerful for the developer to come out with new ideas for their clients, and with HTML5 fast approaching, that might be a good thing The request for all those modules (google maps, video playlists, content sliders, RSS, etc) might be solved by something like this, as any new module might be defined as a new input template paired with various output level two templates (blocks) to be included wherever we want inside a level one (structural) output template So this is my suggestion, we now might be able to easily develop level one templates but (and correct me if I'm wrong) it's not as easy to develop level two templates. I think this code is a step in the right direction and would value your thoughts on the case I present. Thanks guys, take care
  7. See this : http://www.csszengarden.com/zengarden-sample.html With the use of CSS you can make it look like anything you want. (see a LOT of examples at http://www.csszengarden.com/) My suggestion is if it would be wise to develop a blank template (such as that one) that either came standard with process wire or could be auto generated by PW2 when there's no template file uploaded for your new custom page? See, the beauty of it would be that you get a blank template that only needs you to plug in the CSS to make it look as you need it to be. An online template editor/creator integrated would be much better IMHO, more so if PW2 would allow you to set up specific options while editing a field type, to assist you better in creating your simple templates files that only need the proper CSS file to change how they look.
  8. How would one go around presenting this to the website admins without disturbing the core with this customization that would otherwise render itself useless if/when you upgrade PW? Would you need to develop a whole new admin area inside PW separate from PW's admin area?
  9. Well, i had a client who was simply overzealous about their servers, and that's just it... I worked with them on my localhost, presented all the things to the client, after all the approval processes finished (damned committees and bureaucracy) I gave them a CD with the php files and a big sql file and specific instructions on how to deal with them, they didn't understood, so I had to go there and install them under close supervision of the IT admin (who knew close to nothing about anything linux related). Every time I had to change something, I would just use a recreation of the folder structure present in their servers, do the changes and commit them in a CD (with instructions like:"just copy all this files to replace the one's you've got). I know this is not an ideal scenario but it happens, it has happened to me once and I would like to see if there's a possibility that would allow me to save myself from such hassles. As for the images, well, if we have a simple online template editor (nothing more than just a text area to copy paste the code developed elsewhere, that would save as a template file as required by PW2, then we could get a client who required their images to be a specific size, but now want their images to be another size. In this scenario, PW2 would generate the images for each size. If we deal with just a small amount of images, that's not an issue, but what if, as time passes by, they change their design and literally thousands of images need to be recreated using the new dimensions? Old images stay there wasting valuable server space... The template creator/editor should not need to be anything fancy, it doesn't need to be more than a simple text file editor so we can easily copy/paste the text that needs to be on the server. Why? Because of the scenario I described above, but also so we can make small adjustments easily. This would not mean we save templates to the database though, it would save the php files where they belong and that's it. I guess the option would be to integrate something like FileThingie into the admin. http://www.solitude.dk/filethingie/ By the way, what I ended up doing with that client is installing ajaxplorer http://www.ajaxplorer.info/ but for most sites this might be too much.
  10. What if instead of just unpublishing by date there's a list presented to you somewhere for all those pages that have an expiration date so that they allow you to either unpublish, delete or update/duplicate with today's date if needed? This presents more flexibility to the admins. Here's the scenario: you have an advertisement page type that you populate with links or banners from your clients. The ad campaign could run for a month, expire and appear on such a list for you to update with a new ad. Or a set of pictures from your audience with a "Flag as inappropriate" button, once the button is pressed X times it's sent into this list for you to review and unpublish/delete.
  11. Is this possible? The advantage here would be making it easier to deploy an intranet application developed with PW2. It could also be interesting to have the possibility to keep SQLite as a way to maintain yet another backup of what's on the MySQL database... What do you think about it?
  12. Please have a look at this HTML template >> http://famousthemes.com/primely/ The design is made so that many pages seem to request lists of data that would belong to another page: Featured entries on a portfolio (which call all titles, all images and all descriptions each group in it's own div, for the animation to work), A list of subpages of some sort Latest updates Latest blog entries A list of categories (which could be weighted by popularity or not) A list of client testimonials. And that's only the first page, if you explore more, you'll find that many other pages kind of do the same as well. So, my question would be, how would you call a list of entries from a set of pages into a different page? Or rather, how do you call many different sets of pages' data into one single page template? Thanks
  13. The way it is now, PW2 doesn't come with an easy way to publish or unpublish stuff, I think there's an easy solution for it and would like to suggest that we use the same paradigm as the forum topic list. A main list showing the existing pages types that had controls to the right of how many pages we have, a button or two with functions like unpublish all, edit,.etc but most importanlty a button that lists the pages under that main page type. Look, english is not my first language so I'll call them 'publication types' just for my own clarity's sake. A table would list different publication types, and if you click on a list item, it would show you another table (much like the one that lisits forum topics in this board) and would display things like number of views, CRUD controls for that entry, etc, a button to back up, publish and unpublish that entry, etc. What do you think?
  14. There are times when we deal with clients that will either not allow us to access their servers directly or where we don't get FTP access to. I think that it would be interesting to have somewhere in PW2 a small file manager, nothing that fancy, a simple text editor as an option for when this kind of things happen and a way to delete old unused images (since the ones we still have and need will be created again by PW2 when viewed). I know there are already cool things like ajaxplorer, but I also think that it would be a great thing to have this as a standard module for PW2.
  15. Hi guys, I was just thinking... Could we benefit from a blank template? It's interesting to have an almost live example of a site just after we install PW2, but maybe by having a blank standard template it would be easier to have programmers program and designers do their magic. Remember the CSS Zen Garden? A blank template would also mean that both programmers and designers can work at the same time, or that it would be easier to port a template from another CMS (an existing site perhaps?). That's not to say that this should be how it's done, but it might be an option. What do you think?
×
×
  • Create New...