Display Simple Pages entry in index.php

I'm looking for a way that other back-end users/contributors can edit a block of text on the index.php file without modifying the source code.

In specific, I'm wondering if an entry from the Simple Page Plugin Text box field can be called to display on the index.php and other .php files?

Nathan, that's a very interesting idea! We currently do not have a helper function to do this, but if you know a little PHP you can hack it like this:

Change SimplePages/views/page/show.php to look like this:

<?php if (isset($wrapit) && $wrapit == false) : ?>
<?php echo eval('?>' . $page->text); ?>
<?php else: ?>
<?php head(array('title' => html_escape($page->title), 'bodyclass' => 'page', 'bodyid' => html_escape($page->slug))); ?>
<div id="primary">
    <h1><?php echo html_escape($page->title); ?></h1>
    <?php echo eval('?>' . $page->text); ?>
</div>
<?php echo foot(); ?>
<?php endif; ?>

In your index.php page, add this code to see the a simple page with the slug "about":

<?php

    	function getPageByPageSlug($pageSlug) {
                $table = get_db()->getTable('SimplePagesPage');
                $select = $table->getSelect();
                $select->where('s.slug = ?', array($pageSlug));
                $pages = $table->fetchObjects($select);
        		if ($pages) {
        		    $page = $pages[0];
        		    return $page;
        		} else {
        		    return null;
        		}
    	}

    	$pageSlug = 'about';
    	$page = getPageByPageSlug($pageSlug);
    	if ($page) {
    	    echo $this->partial('page/show.php', array('page' => $page, 'wrapit' => false));
    	}
?>

Of course hacking SimplePages like this will mean that if you upgrade SimplePages, you'll need to replace the page/show.php page again.

Let me know if this helps. I'll see if we can add a helper function to make this easier in the next version of SimplePages.

Thanks Will! This works like a charm. Exactly what I needed.

Now I'm wondering if there's a way to remove the About page (in this example) from the dynamic nav menu so the content doesn't double up, while still allowing "normal" Simple Pages (simple pages that aren't called into .php files) to display dynamically in the nav menu?

Have you tried editing a simple page and unchecking the "Link to this page on the public navigation?" checkbox?

Geez. Right under my nose. Thanks.

Hello all. I'm trying to do this exact same thing (insert the content of 'About' Simple Page inside a section of my index.php) but it's not working with Omeka 2.3.

I tried replacing the name of the database, from 'SimplePagesPage' to 'simple_pages_pages' but still not working.

Any ideas?

This thread is pretty old, so everything will work differently in current versions of Omeka.

It sounds like the newish shortcodes feature might do the trick for you.

Instead of inserting simple page content into the index.php file, you'd build a simple page that uses shortcodes and any text you want. Then, in the Appearance->Navigation settings, make that simple page your home page.

Hi Patrick, thanks for your answer. But it doesn't solve what i need. Let me explain:

I modified Seasons theme so the index features stuff modern sites have: widescreen layout, fixed nav bar, full width image and video backgrounds and parallax effect. So i have different sections in the home page (index.php), each one has the screen full height, and you can scroll down.

I was told the admins should be able to change the content of one of those sections, with text and images, using the crontrol panel. That's why I tought the solution was to "embed" the contents of an specific Simple Page into that section.

Can i do that with the get_db() method?
just take the contents of the simple_pages_pages column where slug = about, and print them in a section of index.php ?

Help please! :P

Ah! Yes, that makes sense, and is an interesting case. I can imagine a simple pages shortcode to make this kind of situation easier.

For now, this sort of thing might work

<?php
        $simplePagesTable = get_db()->getTable('SimplePagesPage');
        $slug = 'about';
        $pages = $simplePagesTable->findBy(array('slug' => $slug));
        $page = $pages[0];
        echo $page->text;
    ?>

Hope that gets closer.

Thanks again Patrick. After a little strugle, I ended with something very similar:

$pageSlug = 'about';
$db = get_db();
$page = $db->getTable('SimplePagesPage')->findBy(array('slug' => $pageSlug));
if ($page) {
echo '

';
       echo $page[0]['title'];
       echo $page[0]['text'];
       echo '

So, how do you know how to call the different tables? 'SimplePagesPage' and not 'omeka_simple_pages_pages' in this case?

When i finish this mod to Seasons, Iĺl make it public. It looks good with the fullscreen bg images. :)

My next challenge: I have an Omeka site as "directory of museums", with each museum as an Element, containing a pic, small data, and a link to that muesum's website. Each individual museum's website is another Omeka, with it's own Elements, Collections and Exhibits.

Well, they want a menu that can display, in the "directory of museums", ALL the exhibits from ALL the different museum's Omeka websites.

I guess I can do it using this same database functions, I would like to know them better. Not many exemples of this kind of use over the web.

Thanks again!

Generally in Omeka 2.x, when getting the table that way you go with the CamelCased name of the model. Look in Omeka's models directory, or the models directory of a plugin, and the names of those models are what you use there.

Interesting case of Omeka displaying museums! I say that having built a similar museums site a while ago, but it isn't much maintained right now. I'd love to see what you are working on to compare approaches!

As to your question about it, I'm not quite following the structure you describe. Are these all in one Omeka site? If it is publicly available, that'll help so we can look around at your approach.

Hi again,
No, im making each museum as a single Omeka site, and another different Omeka site as the "directory of museums".

After reading some posts here in the Forum, I tought it was the best option. Do you agree?

So, in the Omeka site designed as "directory of museums", I will display a menu with all the exhibits from all the other Omeka sites. So I think I can populate that menu with the contents from the Exhibits tables of all the other sites.

Very nice museums site you made. I like your "Find me a museum!" widget. By now, my development is not public yet, but as soon as it is online Iĺl let you know.

Thanks again Patrick!

That actually seems like a lot of overhead to me. Instead of maintaining however many different distinct installations, it seems from what I hear like all their content could be put in one site, and just do some work with the navigation settings -- and custom theming and pages that you are already doing -- to direct site visitors.

Especially if the idea is to point to different exhibits from the different museums, that's much more easily handled if they are all in one Omeka installation. Having them all separate, with another meta-site that's really just a directory, sounds much more easily done and maintained with one site and many exhibits and collections.

Thats what I tought at the beginning, and Im still unsure (I have just 2 installs by now). The dilemma is:

What is easier, to have multiple Omeka sites (as you said, not a very good idea);

or

Put all the museums in one site and customize the admin, so the maintainers of each museum can access only the collections, exhibits and elements of their own, without the possibility to mess with other's museums stuff?

AH! The access issue comes up more and more frequently.

A strictly personal note -- I tend to think that the fears about other groups of people messing with other groups' collections, exhibits, etc. is a bit of a red herring. Practically speaking, I doubt that much damage would happen.

But, to build that sort of access control into Omeka would call for a plugin, and UI of some complexity, to handle that.

Sounds like a balance of maintaining many different sites (a technological burden), versus having everyone in one site playing nicely (a social burden).

My -- again personal -- inclination is to go with one site. The ultimate costs of the technological burden are pretty high.

Well, I think you are right: One single Omeka install is more reasonable. That's what Iĺl do. Too many museums for the other option, anyway (121)!

And, just for the sake of conversation, about your personal observation: I know what you mean, I thought the same at first glance. But then I recalled the size and nature of my institution (INAH). I saw you have a PhD in literature, just think in Kafka's "The Castle". That's where I work! :P hehe
Also, I was asked explicitly to make it easy to admin and with clear separation for each museum.

So, I guess I'll find a way to separate or filter which elements, collections and exhibits can be seen by each admin. Maybe trough the field owner_id of the tables.

It's a big and interesting project, we have all the digital assets of Mexico's cultural heritage and we are making the main repository (Mediateca) with Fedora and Islandora, and all the INAH museum's websites with Omeka, retrieving the Mediateca's different collections via Fedora Connect. We have hundreds of collections, some containing hundreds of thousands of items. We wrote modules for MODS creation and items ingest to Islandora.

Eduardo--we have a similar setup with Fedora and Islandora, and we're going to be looking at how best to integrate it with Omeka. Would you be willing to talk about your process? My email address is

rachel [dot] donahue [at] ars [dot] usda [dot] gov

I'll be out of the office next week, but would love to hear from you!

Hi Rachel, sure! it would be great to share ideas and experiences. I'll send you and email.

Have a nice week!