Routing and Content

On this page

Frontend: Content driven
Mandatory SEO and URL contract
German marketing structure and /trash
Administration: Parameter-driven
Mixture of both worlds
Module variables
Remember variables
Session variables
Protected module variables
target {i} and dbx target {i}

dbxapp knows two main ways to call a function:

Content-driven via permalinks and CMS pages.
parameter-driven over dbx module, dbx run1, dbx run2, dbx run3.

Both paths can be mixed.

Frontend: Content driven

In the front end, dbxapp is normally CMS- and Permalink-driven.

Example:

/kontakt
/de/service
/lkw/angebot

The request is resolved to a CMS page. This page may contain normal content, templates and module inclusions.

Example in content:

<h1>Meine Anfragen</h1>

[modul=dbxContact]dbx_run1=tickets[/modul]

The frontend thus remains editorially controllable. Technical functions are embedded as modular islands.

Mandatory SEO and URL contract

Public content has exactly one indexable URL:

The configured German homepage is under the basic URL https://dbxapp.de/ issued. The internal permalink Home remains compatible for content resolution, /home Responds permanently with HTTP 301 /.
Normal German, English and Spanish content sites use their respective clean permalink and a self-referential canonical.
If the permalink resolution recognizes a unique permalink in another language table, this language is automatically activated for the request. Language-dependent content URLs therefore do not require a cookie or dbx lng-Query and are directly accessible.
http://dbxapp.de/* and https://www.dbxapp.de/* In one step, https://dbxapp.de/* unified.
Use internal homepage links {dbx:base href and do not recreate the alias Home.

dbxContentRenderer Canonical, Robots, Open Graph, JSON-LD and hreflang as system values. dbxTPL It creates the central {dbx:head metablock. Any complete design HTML with <head> must contain this placeholder exactly once directly in the head:

<title>{dbx:title}</title>{dbx:head_meta}

A design may: No one of his own fixed <link rel="canonical"> define. This means that the same URLs and robots rules apply in dbxapp, Flowers, Stealing, windows, intro and editor pages. Technical routes with dbx module, dbx run *, dbx action, dbx edit, dbx token, Ajax or window context get central noindex,follow; a simultaneously loaded content record must not use this rule with index,follow overrule.

The XML sitemap contains only active, publicly readable content permalinks. It does not contain login, shopping cart, account, admin, promotional or other ?dbx *-URLs and runs the German homepage only as a basic URL. robots.txt allows crawling and refers to the sitemap so that search engines can noindexmetadata of technical pages.

The regression test dbx/include/tests/dbxSeoCanonicalPolicy_test.php Secures Redirect, Canonical, Robots, Sitemap Contract and the head metablocks of all designs. After a production publication, /, /home, a normal content page, a language page, a technical route, sitemap.xml and robots.txt checked. Only then will a new validation be initiated in the Google Search Console.

German marketing structure and /trash

The German website is the relevant public version. Your navigation is limited to a few clear areas:

Solutions: Overview, CMS and website, shop and multichannel, individual applications, intranet and portals as well as dbxKi.
Platform: Technology, packages, references, demo and contact.
Developers: Developer overview and documentation.

Public landing pages use the content template c-marketing body1 footer. The modular bar provides the only first order heading; the page content then begins with introduction and headings from level two. Title, description and content use real German umlaute. The product name is always dbxapp.

Redundant, unfinished or only for test purposes pages are not deleted. They will follow /trash postponed and received binding:

Activ = 0
addmenu = 0
group read = admin
meta robots = noindex,nofollow

The folder /trash itself is only for the group admin legible. Help and tutorial pages that are still needed internally remain active but do not appear in the menu and use noindex,follow.

Old German marketing permalinks remain as language-dependent HTTP 301 redirects in dbx/modules/dbxContent/cfg/config.php obtained. The detection takes place centrally in dbxWebApp; Module and action routes are not changed. The standard language German continues to use flat canonical URLs. English is clearly under /en/ delivered. The sitemap therefore contains both released language versions, and hreflang links pages with the same lng uid.

Administration: Parameter-driven

In administration, URL parameters are the default.

Example:

?dbx_modul=dbxAdmin
?dbx_modul=dbxContact_admin&dbx_run1=list
?dbx_modul=dbxAdmin&dbx_run1=config&dbx_run2=edit&xmodul=dbx

The main class of the module evaluates dbx run1 Delegates to Include Classes.

Minimum router:

class myModule {
   public function run() {
      $run1 = dbx()->get_modul_var('dbx_run1', 'list');
 
      switch ($run1) {
         case 'list':
            return dbx()->get_include_obj('myModuleList')->run();
         case 'edit':
            return dbx()->get_include_obj('myModuleForm')->run();
      }
 
      return dbx()->get_system_obj('dbxTPL')->get_tpl(
         'dbx|alert-warning',
         array('msg' => 'Unbekannte Aktion.')
      );
   }
}

Mixture of both worlds

A CMS page can contain an admin-like module:

[modul=dbxContact]dbx_run1=tickets&status=open[/modul]

An admin dashboard can only define layout:

<div class="dbx-admin-dashboard-slot dbx-admin-dashboard-slot-sysmsg">
   [modul=dbxAdmin]dbx_run1=sysmsg&dbx_run2=list_sysmsg[/modul]
</div>

The parent template only decides on position. The integrated module remains responsible for content, reports, filters and actions.

Module variables

get module var() reads module-related parameters. It is the standard within a module.

$run1 = dbx()->get_modul_var('dbx_run1', 'list', 'parameter');

$id = (int) dbx()->get_modul_var('id', 0, 'int');

get request var() Reads direct request parameters without module protection. It is used when a value is really global for the request.

$ajax = (int) dbx()->get_request_var('dbx_ajax', 0, 'int');

Remember variables

Remember variables store UI or system states across requests.

dbx()->set_remember_var('dbx_lng', 'de', 'dbx');

$lng = dbx()->get_remember_var('dbx_lng', 'de', 'dbx');

Typical values:

Language: dbx lng
Design: dbx design
Edit mode: dbx edit
Colour /Skin: dbx color
Report selection status

Session variables

Session variables belong to short-term user status.

dbx()->set_session_var('selected_ids', array(4, 7), 'report', 'dbxAdmin');

$ids = dbx()->get_session_var('selected_ids', array(), 'report', 'dbxAdmin');

Protected module variables

dbxapp must allow the same module to occur multiple times on a page. Therefore, module status, report state and targets must not collide globally.

Example:

[modul=dbxContact]dbx_run1=tickets&status=open[/modul]

[modul=dbxContact]dbx_run1=tickets&status=closed[/modul]

Both instances require separate filters, pagination and AJAX targets.

target 1 and dbx target 1

{i} is from dbxForm/dbxReport replaced by a current instance number.

Template:

<div id="dbx_target_{i}" class="dbx-panel dbxReport">
   <form action="{action}" method="post" id="dbx_form_{i}" class="dbxAjax"
         data-ajax-target="dbx_target_{i}" data-ajax-replace="target">
      ...
   </form>
</div>

Rendered output:

Why this is important:

AJAX replaces just the right area.
Several identical reports can exist on one page.
Windows, Confirm and Reloads have a clear goal.
No ID collisions in the DOM.