Im working on simple PHP CMS system and Im stuck with database design.
This is the problem.
I have table named pages, it holds all pages I can add and information about this page like page_url, page_order etc..
Now... Every page can be either webpage that can hold some html content. But it can also be a Blog or anything else. There can be only one blog page. And Blog on the other hand can have blog posts and blog categories.
Simply put, I have pages table that represents all pages I can create.
And every page can be different, it can be webpage, blog module, guestbook, contacts page.
And every page will have different purpose.
So the problem is how to design this?
Now this may not be clear at this moment, but here is my current design so maybe it will be easier to grasp what Im trying to achive:
pages
page_id
page_name
page_url
...
webpages
webpage_id
page_id
webpage_content
webpage_date_created
...
blogs
blog_id
page_id
...
blog_posts
blog_post_id
blog_post_title
blog_post_content
...
blog_categories
blog_category_id
blog_category_name
blog_category_url
...
So, I have pages table that holds all pages, but those pages can be either webpage(simple "static" webpage) or it can be blog, and blog can have posts, categories etc...
So now, if I come to the page which id belongs to webpages template, I joust fetch content and stuff i need and hand it back to controller and the view.
And if I come to the page which id belongs to blog, then I fetch latest posts and show that to the user.
And latter I would like to extend pages so page can be guestbook or anything else.
Basicly, I need database design where pages would be stored in pages table, and each page can be seperate module that would be presented on different way.
Is this the way to go like I described above? Or could it be done better?
Am I doing something wrong here?
There doesn't seem to be anything fundamentally wrong here - you're using object-oriented conventions, which I can't encourage enough. If I understand, all of your pages will be listed in the PAGES table, and then will be connected by PAGE_ID to their appropriate category?
This allows you to continue to add different page types if you so choose, as well as keep a single list of all of the pages present on your site.
The only thing I would add, is perhaps a 'type' column in your pages table. Even though you'd be able to determine this by running a page_id query on the other (blog and webpage) tables, it might make your life easier in the long-run if you're interested in really scaling and being able to gather a quick since of your application makeup (25% static pages, etc, etc).
This layout also would allow you to combine types (if a page_id was present in the blog and webpage tables) you could introduce some static content while also dropping in your dynamic blog features.
Looks good to me:)
Use a "type" column to specify what type of content the page contains. Then use a join table to associate your content with your page. Like:
pages
->id [123]
->type ['blog']
blogs
->id [123]
->title ['My Blog']
pages_blogs
->id [123]
->page_id [123]
->blog_id [123]
Related
I have the following challenge:
I have a Moodle system and would like to track visitor activity in the courses via Matomo.
The problem is that one course has several activities, but they are found under a different URL structure.
Example: My course has the URL /course/view=1 and also has a few activities that can be found under three completely different URLs (e.g. /mod/forum/view=20, /mod/feedback/view=7 and so on).
Now I would like to have a common tracking for a course room and the activities in it.
Is this possible? Are there any direct solutions for Moodle? Or how could I do this manually in Matomo?
Thanks
It's possible to set a custom URL in Matomo by using the following code in the page:
_paq.push(['setCustomUrl', 'https://yourdomain.com/your-new-page-url']);
You could perhaps do this for all the pages within a "Course" in order to track all of the actions taken in one logical "Page", but this may affect some of the reports for that page (For example page overlay might be broken)
An alternate way of tracking all of the actions would be to set the Page Title that Matomo tracks using:
_paq.push(['setCustomTitle', 'Your Page Title Here'])
This will allow you to group all of the actions under one logical Page Title under the Page Titles report.
I'm new to JSON-LD. I find the syntax fairly straightforward but my query lies more with deciding which pages it is best to add the JSON-LD to. I've spent a bit of time looking for an answer online but so far nothing has been clear.
My example:
The site is for a business that has roughly 20 branch locations across the country. Each office has a dedicated contact details page, and there is also a "contact us" page for the site as a whole.
Should I
A: Add 'Organisation' JSON-LD snippet for the organisation as a whole to the homepage of the site, and then add individual 'LocalBusiness' JSON-LD snippets to each office details page?
B: Consolidate all this into one snippet of JSON-LD that has 'Organisation' with nested 'LocalBusiness'es and place it on ALL office pages, with a separate 'Organisation' snippet for the homepage?
C: Consolidate all this into one snippet of JSON-LD that has 'Organisation' with nested 'LocalBusiness'es and place it on ALL pages sitewide?
D: None of the above... Instead you should ____________________.
I realise there may not be one correct answer for this, but any help at all in achieving what would be considered best practice, would be greatly appreciated!
Cheers
Per the JSON-LD specification, it’s totally up to the authors. Consumers of your JSON-LD might of course have their own expectations.
You seem to use the vocabulary Schema.org, which is sponsored by the big Web search engine services. They are of course typically interested in your page content. The general idea of Schema.org is to mark up your existing content (+ closely related metadata).
This becomes clear when looking at the other syntaxes supported by Schema.org (Microdata and RDFa), as they define attributes that get added to existing HTML elements used for your content. So JSON-LD is the exception here, as it doesn’t get coupled with the HTML/content.
tl;dr: On a page about a branch location, provide structured data about this branch location.
It typically makes sense to provide structured data about related entities (e.g., the parent organization) in addition. This can be done by including the data and/or by referencing it via its URI (see an example). Make use of the properties the type offers (e.g., parentOrganization).
If this question is still relevant to someone, here is my recommendation:
on the homepage, create a "LocalBusiness" markup and use the "department" attribute for each branch.
So in your case, there should be one main office and 19 departments.
For the main office, indicate all attributes (opening hours, logo, image, etc.) For branches, mark up only distinct properties, such as address or telephone (they are apparently different for each branch).
For example, if all branches have the same working hours, no need to repeat them again and again - indicate working hours only for the main office.
Then on each dedicated contact details page add "LocalBusiness" markup only for that specific branch - without departments. You can indicate all attributes in detail.
Do not add "LocalBusieness" sitewide - Schema markup must be relevant to a specific page.
Also, here is an article that can help to understand it better:
https://postelniak.com/blog/local-business-schema-for-multiple-locations/
There you can also find JSON-LD code snippets.
I've presented them all as a list in 3 columns (see here: http://focallocal.org/action/ ) but i need to double the amount there now and it is going to look terrible.
what we really need is filters to cross reference and organize them as the number will grow to over 100 soon. Any suggestions for managing and organizing the large amount of content?
It doesn't have to be on one page as long as i can put a short intro and photo to each page
I suggest making a separate post for each of your project descriptions with a custom post type called "project" or similar to group them all (and so it doesn't affect any ordinary blog posts.)
How to add a custom post type
Next, you need to "flush" the permalinks (Settings > Permalinks, click Save Changes.)
The Project posts can be split into categories or you can add tags (less formal) and each post can have a featured image.
If you called your post type "project", you will be able to view an index of all of them at http://example.com/project, which, taking the TwentyFourteen theme as an example, will use the archive.php file as a template (see the Template Hierarchy.)
I would like to ask you guys if you could review my database design. I think it is quite self-explanatory, but to be absolutely clear:
My goal is to make an application which has a super flexible user management (which is why the groups are in tree-form and the groups and users have a habtm relationship) and a super modular way to build pages (which is why the pages consist of widget-blocks).
The reason I made users and profiles separate is because the users table will not change and is only needed for authentication and authorization. However, the profiles table will change according to the wishes of the client. So it might not have a signature, but an avatar field instead. Or maybe it will be completely empty / not exist at all.
A widget could be anything, it could be a poll, it could be a piece of content, it could be a navigation, it could be a collection of comments, whatever.
The reason I chose to make subdomains, locales and layouts separate tables instead of just putting the names into pages is because I want to limit the options that are available to the client. Just because I have a three-columns.ctp in my layouts folder doesn't necessarily mean I want the client to be able to choose it.
Same goes for the widgets. And besides limiting choice, not every plugin, controller and action in my plugins-folder is a widget, so I need a table to clarify which are.
A block is a widget on a page which sits in a container (e.g. the right column in a 3 column layout) at a particular position which is decided by the index (lower index means higher).
So that's my explanation, what do you guys think? Is this as good as it can be? Or do you have (a) suggestion(s) to make it even more flexible and modular.
[edit] Oh and to be clear, the widgets will of course have their own tables to store the information they need to store.
Well, I think that everything is great except "profiles".
When you try to get data from a logged user:
$this->Auth->user();
I don't think that you will get data about "profiles" so you will have to find profile by $this->Auth->user('id') etc. I think that you should merge "profiles" and "users" tables into "users" table.
So when you want to save, let's say, "signature" you should just put it in $this->request->data; and call $this->User->save($this->request->data); and the signature will be updated.
EDIT:
You can leave it the way it is but, to get other data than user, you will have to put:
$id = $this->Auth->user('id');
$current_user = $this->User->findById($id);
I am developing a web site using ASP.NET MVC. The site will be similar to StackOverflow in that there will be user submitted items that will have a numeric id and a textual title.
Now I am thinking how to design the URL routing system for the "item details" pages. I had thought of using the id alone (as in http://www.mysite.com/items/1234) or the title alone (as in http://www.mysite.com/items/how-to-foobarize-a-fizzbuzz). I see however that StackOverflow uses instead both of them (as in http://www.mysite.com/items/1234/how-to-foobarize-a-fizzbuzz).
So which one is the best approach? And what is the point of using both the id and the title in the URL? Isn't this redundant?
Yes, having both ID and title (which is most often called slug) is redundant, but it's cool both from SEO and UX standpoints.
There's one personal dislike about how it's done here on SO, though. I can't seem to understand why an ID is separated from a slug with a forward slash (/7754456/urls-for-item...). To me, each segment implies some sort of hierarchy, so dash will be more appropriate /7754456-urls-for-item...). But that's just me.
The advantage of using the title in that form (usually referred to as a "slug") is basically just that of URL readability. However, if you are not enforcing a uniqueness constraint on your titles then this will not necessarily be adequate to identify a record. Therefore, when both are used, the ID can be there for the server to actually to do the lookup and the slug is there for humans to read.