Jump to content

jmart

Members
  • Posts

    16
  • Joined

  • Last visited

Everything posted by jmart

  1. After working with blocks in Drupal, I now find it easier and more maintainable in PW to hard code the blocks using includes (or direct code) in the main template and wrapping if/else logic around each block. Sometimes you may want a block to be configurable by the client. So in PW, create a template and render an instance of that template directly in the sidebar of the main template. This way, all the logic of what gets output in your sidebar can be easily traced and version controlled rather than being set in the database. Because PW uses page hierarchy, there are cool things you can do like query which section you're in ($page->rootParent() I think) and output a certain "block" based on that section. You can also use a page reference in a "block" template and and pass your current URL to a query of those template instances and output anything that matches. If nothing matches on that URL, ask the current page's parent if there is a match and do on up the tree until you get to home. That's how I let a client override a header image on let's say Home / About / Our Team. They create an instance of "header_image" template, upload an image to it, and choose Our Team as the page reference. The code checks to see if there is a match on /about/our-team. If there is, output the image. Else ask to see if there is a match on just /about. Else default to the header image for the homepage. You actually use a for loop to do march up the tree and end if you hit a match or the root.
  2. Yes! As some say in my country, muchas gracias! I like the config.php idea. And Soma, thanks for pointing me to a previous article.
  3. Thanks Ryan, Willy, et al... I'm sorry if I'm beating a dead horse here. But setting up extra roles and templates just so that I can mark certain pages as un-deletable or un-editable or un-moveable seems like overkill. The reason being is if we start using PW, we will be using it on about 5-10 sites a month. We do a lot of business. And we just need to do this once per site for a few pages. Perhaps it would be easier if I could hardcode certain page ids as un-deletable or un-editable or un-moveable using a module. I don't know enough about the hook system. But the logic is: $do_not_delete_array = array(101,150,151); if(in_array($page->id,$do_not_delete_array)){ //display error - We're sorry. This page can not be deleted return false; }else{ //process a normal delete }
  4. jmart

    bigair.tv

    Hi thomas, You may want to checkout http://www.google.com/webmasters/tools/richsnippets It shows "Page does not contain authorship markup" which you may want to add. For example: <a href="https://plus.google.com/YOUR_GPLUS_ID? rel=author">Google</a>
  5. I have an existing non PW site that I want to convert to PW. But even though the menu structure has depth, the URL structure is flat. For example, what should be /about-us/our-team is simply /our-team Rather than dealing with the 301 nightmare, it would be nice to change PW so that it wouldn't prepend the parent's URL. And I don't want to "teach" the client to override the URL for every page that is created. Any suggestions?
  6. What any newbie should do first is learn Drupal. After 2 years of: awful theming, i.e. $element['#object']->field_video_embed['und'][0]['value'] instead of $page->field_video_embed searching through 500 line arrays to find out what module is injecting a certain markup in your code writing huge css files to deal with the divs nested within divs nested within divs nested within divs figuring out how to add a meta tag to your <head> using an API and an array getting carpal tunnel syndrome from constantly clearing the cache because Drupal is such a hog, everything has to be cached learning the Views module, a point and click interface that is 3X more annoying and difficult than learning and using straight SQL find a good host that is beefy enough to deal with the Drupal and has advanced caching capability After that, PW will be a walk in the park.
  7. If you want to be a web designer / developer: Create a personal website. Place your résumé and career goals on the site. Add a portfolio of different projects with screenshots, code samples, and links to real sites you've worked on. Make sure the links work! List your skills and what web CMS's you work in. Add a contact page. If you aren't a designer, don't post work on your own crappy design. Use a professional theme and focus on your development and integration skills. Otherwise you look like a hobbyist. Run everything you write through a spell and grammar checker. Go to places like elance and Odesk. Work for cheap until you have some good experience. Do a website for your brother-in-law's business or a local school or charity. Put some meat on your résumé/site. Why all this? I own a web design company and I get job requests every day. If their emails don't have a link to an online portfolio, I hit delete.
  8. jmart

    bigair.tv

    Good example of microdata use on the videos and on OG tags on all pages. You place microdata on http://bigair.tv/video/vagabond-ritual and other videos. Are you planning on adding microdata to your other pages such as Product and News Articles?
  9. Still not seeing it built into core. Please tell me how I can setup a role called "client" who: can edit a page of template "top-level-page" cannot delete a page of template "top-level-page" but can edit and delete pages of template "basic-page", "faq", "event", etc.
  10. Hi Ryan and Soma and Dave, thanks for getting back to me. In the Edit Template for Basic Page under Access, I see the following permissions: View Pages Edit Pages Create Pages Add Children Ideally it would be great if there were two other permissions: Delete Pages Move Pages I would think that "Delete Pages" would already be there. Perhaps I'm missing a setting somewhere. Locking the template seems to lock the client out of edits. But I want to allow him to edit the page, just not delete the page. But barring a new release of PW with my wishlist of new permissions, perhaps I could write a module where at least I could hard code these permissions for certain page ids. Restricting Deletion while allowing Edits would be crucial. Restricting a page so that it cannot be moved is a "nice to have". A lot of my requirements are on a page by page basis where it would be nice to mark a certain basic page as "un-deletable" or "un-moveable" while keeping the same template for other pages where the client would have free reign. If you could help get me started, I would appreciate it.
  11. Let's say I have a page that I don't really need a template per-se. It's a one time page with no fields. Maybe it's a page with a form on it, or a big 3rd party iframe, or an htm image map (remember those?). Do you just use a basic page and then put an if/else statement in basic-page.php? If($page->id == 1003){ <iframe .../> }else{ //render content as normal ... } Or are there other strategies for dealing with these edge cases?
  12. Just read a post by Soma at http://processwire.com/talk/topic/1036-markupsimplenavigation/?p=9082 about his MarkupSimpleNavigation module. By passing an option into the options array, you can exclude pages. For example, I have a page called Sitemap (id = 1017) that I want to exclude from the top navigation. <?php $mainMenu = $modules->get("MarkupSimpleNavigation"); $menu_options = array( 'show_root' => true, 'max_levels' => 1, 'collapsed' => true, "selector" => "id!=1017" ); echo $mainMenu->render($menu_options); ?> Then for the footer navigation, I can run the same code as above but just take out the "selector" portion. Now my footer navigation will include the link to "Sitemap".
  13. Thanks Soma and DaveP. I'll test the module out this weekend and see if it meets my requirements. I'll also dig around in the code and see if I can adjust anything in my own module.
  14. From reading about Page Edit Per User, it doesn't sound exactly like what I need. Let me bullet point my requirements: Client can create/edit/delete/move a "Basic Page" template Superuser can flag a specific "Basic Page" page (or any other page type) as:Either editable or not Either moveable or not Either deletable or not ReasoningClient can create all the basic page he wants But there are some pages he just can't do certain things to like:I don't want him deleting a top level about page because it would ruinthe design the site structure URL structure Section specific CSS styling, code, php includes, etc. I don't want him moving a page from the top level for the same reasons I don't want him editing a certain page that I did a lot of custom layout for I don't want him deleting a page that a lot of code is dependent on that page existing I don't necessarily want to build separate template files for top level pages I don't want to assign which pages a client has CRUD rights to because he should be allowed to CRUD new child pages at will. I would be happy with any solution, whether it can be done using an admin panel or if I have to hard code certain page id(s) as being restricted.
  15. I am new to PW. For top level pages like Home, About, Contact, etc., and on specific pages like /contact/thank-you, I want to restrict my client from deleting or moving those pages. This is so that I can preserve the site structure and keep my client from breaking the site. I still want my client to be able to edit the pages, just not delete or move them. For a page under the top level, e.g. /about/mission-statement, the client can do whatever he/she wants. It would also be great to specify that a certain page cannot be edited or deleted except by the super user. Without creating and maintaing separate templates for these top level pages (assuming that they are basic pages that use the same fields), what is a good a method to restrict the client? Can I create a module with a hook? Or is there an inherent core or contributed module that can handle this? Or do I need to create separate templates? Also, is there a way to restrict clients from deleting pages that have children?
×
×
  • Create New...